R-Comp develops audio rip'n'encode app

By Chris Williams. Published: 26th Feb 2004, 16:57:16 | Permalink | Printable

I am the MusicMan, I come from far away and how much will you pay?

Software publisher and dealer R-Comp has developed MusicMan, a fancy new commercial application that plays CDs and allows users to convert CD tracks to MP3s using Peter Everett's shine tool. MusicMan also displays and catalogues track information, such as titles and album names, which can be fetched from the internet using something like FreeDB, at a guess.

"The software is designed to be extremely easy to use, with a clear and straightforward interface. Information about the disc and track titles can be looked-up on the internet and audio extracted and converted in one or two clicks of the mouse," exclaims the R-Comp announcement. R-Comp also stress that users should "comply with any copyrights associated with their audio CDs". Touching.

Some older CD-ROM drives may experience problems in ripping CD audio, R-Comp warn. As a side note, we'd be interested to find out if MusicMan is any good at evading recent anti-copying measures being embedded in a growing number of CDs available on the high street. MusicMan goes on sale from Saturday as its release coincides with this weekend's South West show.

Links

MusicMan website - pricings, details, etc.

Previous: AcornArcade to re-release Cooper classics
Next: Castle unveils new Iyonix case

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Nice to see a new commercial application.

This looks rather good for the money.

fylfot on 26/2/04 5:18PM
[ Reply | Permalink | Report ]

Yay, R-Comp bundles another lot of free software into a commercial app!

simo on 26/2/04 5:42PM
[ Reply | Permalink | Report ]

Sadly no support for the *.ogg format. I dropped *.mp3 almost a year ago.

Sincerely Hauke

VLIW on 26/2/04 7:55PM
[ Reply | Permalink | Report ]

Eugh, Shine. Last time I heard that, the encodings were *awful*. Still, nice to see R-Comp repackaging other's work with a pretty UI

(if anybody writes things like this, I strongly discourage the use of CDDB or FreeDB - they're full of cack/wrong entries, and don't cope gracefully with multi-artist albums. Look at www.musicbrainz.org instead - their library has a horrible API, but the system itself is much better thought out - even letting you look tracks up by the way the sound!)

nunfetishist on 26/2/04 8:00PM
[ Reply | Permalink | Report ]

nunfetishist> The reason that shine sounds so poor is quite simple - it doesn't have a psychoacoustic model.

As for FreeDB, I've found it to be relatively accurate for most of the albums I have and it's only the obscure ones that it fails on. However, it really does depend on how much you use it and what genre of music you're into. It's an incredibly wide field. Plus, of course, very few CDDB/FreeDB clients actually support the alternate database entries for similarly hashed albums which doesn't help in the slightest - corrected entries are never even given as an option to the user. It would be interesting to know whether MusicMan provides such an interface. Or whether it's based on AcornCD.

Gerph on 27/2/04 11:52AM
[ Reply | Permalink | Report ]

Reading that back, I realise that the first comment doesn't actually mean much unless you understand a little about MP3.

MP3 is the common name for MPEG audio layer 3. Strictly the MPEG audio it refers to comes from the MPEG 1 and 2 specifications, together with the later 'MPEG 2.5' additions for lower frequencies. MPEG audio consists of three 'layers' of compressing the data. In general these aren't layers of processing but of understanding of the Audio data itself - the processing involved at each layer can be considerably different.

Originally Layer 1 was intended for most purposes. It has a low processing overhead with a moderate amount of compressing resulting in reasonably siZed files. Layer 2 was meant for more demanding audio situations, where processing could be performed more quickly and the compression had to be better to provide improved quality. Layer 3 was again more processing intensive for situations where compression for the same quality was paramount - although invariably the result was that the same siZe of output was required, but higher quality, rather than retaining the quality level and reducing the siZe.

And so we come to what MPEG audio include. Layer 1 is simplest. It understands that there are different frequencies which are heard more by the human audio reception system (ears).

Layer 2 is more complicated, taking into account the temporal effects that are present within the sounds. This means that the sound that is heard isn't necessary that which was being produced at that instant. A high energy sound (loud drum, for example) will hide the sound of a voice - that's obvious from your own experience, I hope. What may not be obvious is that the drum actually hides other sounds after it has stopped. I don't know the reasons for it - I assume that the sound is still being processed and continues to hide the other sounds even when it's stopped. You can find various papers on this sort of thing - that's why it's a clever format; clever people worked on it.

Layer 3 adds more to this, allowing for temporal effects which span into the past. It seems that the sound of the drum not only hides some frequencies that follow it but also some frequencies that occur in those moments before the drum starts to sound. I guess it's the delay between hearing and processing the sound in the brain that gets shortcut by this louder sound, making the brain just give up on the earlier bits and start on the big loud sound that's happening. All this is happening on fractions of a second so you really don't care as you're hearing it, but the fact that it is happening means that the compressor can take advantage of it. Layer 3 also includes much better compression of the data itself, reducing the siZe of the output by 'huffman' compressing the results of its work. In layer 3, the amount of data that can be stored in a frame (instant of time) can change. When compressing, the encoder can be looking ahead and decide that there's something complicated coming up and store less data about the 'current' sound in its frame. This means that it can have space in this frame for more data about the /future/ frame that is more complex. This is known as a 'bit reservoir' and basically means that the encoders knowledge about the upcoming sound complexity can be taken account of, packing more data in. This is also the reason why you can't just flick to any point in a Layer 3 file and expect it to play. Any given frame may require data from a previous frame.

All this processing that goes on, based on the response of the human ear is obviously based on particular generalised form of the effectively heard sound. But of course, general is not equal to specific. *You* may hear things differently to the generalised form. This is why people will say that MP3 sounds awful. They're making wild, and strictly inaccurate, statements. What they mean is that to them it sounds awful. It really does depend on your own hearing. Similarly it depends on what's being played - one sounds right for one thing might not sound right for another. Take nobody's word for it until you've actually listened to MP3s yourself, and the output from different encoders will produce different results because they use different models.

Which brings us back to the lack of a psychoacoustic model in shine. Shine is intentionally designed as an implementation that pays no heed to any of the perceived sound things that I've explained above (and the ones that I haven't). It applies a very simple model of its own which doesn't relate to the particular characteristics of the human perception.

Whereas the quality of a good psychoacoustic model based encoder can actually be perceived to be very high at low bitrates, shine doesn't have that advantage. At low bitrates it can't take advantage of the knowledge about what will actually be heard by the listener because it has no such knowledge. It wades blindly on, producing something akin to noise (IMO). You need something approaching 160kbit/s to get anywhere near a decent reproduction out of shine, and it can't compete with an encoder which uses a good psychoacoustic model at the same bitrate.

So why use a very poor encoder to get a reasonable sound out when your could use a decent encoder to get a good sound out ? Speed! Shine doesn't do much (comparitively). It can be fast. Fast, though, is a comparitive term - as I remember it, shine gets something like real time encoding at 128kbit/s on a SA200 (from memory). LAME (another encoder, wildly regarded as 'good') manages (I'm informed) around 0.1x speed on a SA233 - it takes 10 times as long to compress a file than the sound it contains (1 minute of sound takes 10 minutes to compress). Obviously using shine makes some sense in that respect, but if you actually want to listen to music regularly, rather then you don't want to be listening to something that's rather poor, but a more decent version.

This is one reason why I consider the pitiful 64M siZe of some of the flash MP3 players to be quite pointless - you can't get enough in them at a decent quality. Small they may be, but small does not quality make. (That said, I've got one and it's cute, but only in a 'play with it' way)

My own personal opinion is that encoding MP3s on RISC OS is unproductive. My Laptop encodes the MP3s at 10x speed (1 minute compressed in about 6 seconds) and it's nothing special. I'll just leave RISC OS to do the playback. It's good at that. However, that's just my view... the point was to explain the terminology in, hopefully, a way in which readers might understand rather than to just leave it hanging like an 'I know more than you' comment.

Obligatory disclaimer: This information is based on my own research into what MPEG audio consists of, work on AMPlayer and a lot of MP3s. Oh and my memory. If you don't believe it, it may be wrong. Look it up for yourself; the information's all there on the 'net. Well, all except the actual specifications. But you don't want to read them anyhow. Oh, and understand that I've simplified stuff quite a bit, partly due to memory, and partly 'cos you really don't want to know about some of the inner bits that are ... complicated.

Gerph on 27/2/04 1:00PM
[ Reply | Permalink | Report ]

Woah. That'a a helluvanexplanation. More there than in several monthsworth of TiB articles. ;-)

imj on 27/2/04 1:07PM
[ Reply | Permalink | Report ]

Indeed. I've used Shine quite a bit, usually at 192kbit/s, since I'd nothing else to encode with. Since the music was never going further than my hard disc I wasn't too bothered about size. It only started sounding iffy when I tried playing back with decent speakers, instead of the poor little things I've got. I suppose you may as well wonder why I bother playing music on the computer at all.

SimonC on 27/2/04 2:52PM
[ Reply | Permalink | Report ]

That is true. I'm a bit of an audiophile, and it's very very hard for me to tell the difference between a FLAC (lossless codec) and LAME (lossy) when using headphones. Play it on my hi-fi, and LAME's 256kbps output is noticably worse than the source file. I think when people say that MP3 removes stuff that humans can't hear, they're not *quite* right. They remove stuff that humans can't hear when played through an average rendering stage

nunfetishist on 27/2/04 3:05PM
[ Reply | Permalink | Report ]

... and heard with average ears.

But yes, you're right - the way you actually make the sound does make a difference.

Gerph on 27/2/04 5:19PM
[ Reply | Permalink | Report ]

I knew there was a reason why I don't like MP3s, and think that the RIAA in th US and their equivalent over here are getting their knickers in a twist over nothing. If you want to listen to well recorded music,invest in a modern CD player. Sir Paul McCartney is wrong, black vinyl is, was and always will be a rubbish recording medium.

JWCR on 28/2/04 1:02AM
[ Reply | Permalink | Report ]

Vinyl does have some advantages over CD. It can more accurately place a transient in time than CD can, for example. And it's only been recently (5 to 10 years) that people have worked out how to make lovely CD players that actually sound nicer than vinyl. ie, it used to be true that vinyl sounded nicer than CD.

nunfetishist on 28/2/04 10:54AM
[ Reply | Permalink | Report ]

JWCR> If you're using the explanation that I provided, or nunfetishists view that MP3s aren't particularly good at a particular rate as a vindication of your own belief that MP3s are poor, then you have missed the point that it is all subjective.

The RIAA argument is completely outside whatever technical and perceptive qualities MP3 may have.

Gerph on 28/2/04 11:02AM
[ Reply | Permalink | Report ]

Gerph: It must be that the handful of MP3s I have were made at a particularly low bitrate, or encoded by a particluarly poor peice of software. As a result, my subjective opinion is that I don't rate the format very highly.

JWCR on 28/2/04 2:36PM
[ Reply | Permalink | Report ]

In reply to simo:

Just what ROL do with Seelct then!

robert79 on 2/3/04 5:15PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

RiscPC breaks 1.5GHz barrier
Calm down dear, this is a case mod

23 comments, latest by flypig on 13/5/04 1:56PM. Published: 12 May 2004

Random article

New 800MHz XScale powered processor available
IOP331 or IOP315 in Iyonix mark II?

50 comments, latest by hubersn on 30/09/03 4:41PM. Published: 16 Sep 2003

Create a new account
Forgot your password?

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"Drobe often has glaring factual errors that could simply be avoided with the bare minimum of research"
Page generated in 0.0722 seconds.