CDs to MP3 (using CDEX 1.51)

[Evil Eivind]

I'm sure this question may have been discussed previously, and is probably something that's frequently discusses in other forums. But, regardless, I don't think there'd be much harm in asking it one more time...

What settings/codecs/etc. should be used in order to copy a CD onto the computer as mp3 files with the best results?

Also, I'm currently using CDEX 1.51 to do any and all ripping, with these settings:

Encoder: Lame MP3 Encoder (1.30)
Version: MPEG I
Bitrate min: 192
Mode: Stereo
Quality: Normal
VBR Method: Disabled
Output Samplerate: Auto

My main priority is to get the best sound, and loosing as little as possible in the ripping process, and compression (file size) comes second -- if file size wasn't also an important factor, I'd simply use WAV files.

So what settings should be used in order to get the best results, preferably with as good sound as the original CD, and with a decent file size?

[divad6719]

This is one of the best guides for using CDex, follow this and it will produce high quality VBR MP3 files.

CDex guide

The settings used in the guide are generally recommended to give the best trade off between file size and quality. Most people will find these files as good as the original CD.

There used to be a sticky in the support section with some links, but I don't know what has happened to it.

Cheers

Edit, the filesize will average out at around 220kbps. So not really much more than you are using now, but with better results.

[Evil Eivind]

I've actually seen that guide before. What I don't like about that particular guide is that it only tells you what to do, not why you should do it, nor does it point out the pros and cons of using the method it presents - nor on any other methods, for that matter.

Isn't VBR the most "risky" way to encode mp3s, as you then let it switch freely between different Kbps?

[divad6719]

Yes, but it's also a controlled process. CBR could be regarded as a waste of "bits" as your chosen bitrate (ie 192kbps) will be used over the whole file. So some parts that don't require this bitrate to encode well will still be encoded at 192kbps.
Using VBR means that parts of the music that require a higher bitrate (for better quality) will get that, while parts that only require a low bitrate to encode well will get what they need. So it's more efficient you could say.

--alt-preset standard is one of the recommended settings from Hydrogen Audio, these kind souls have tested it to death to make sure it is as good quality as can be had under the selected parameters.

See Here

CDex's paranoia mode is it's highest setting for ensuring that you get as good a rip as possible from your CD.

Cheers

Edit: When I had my iMP, --alt-preset standard was what I used. I found no problems with it.

[riverrock]

Exact Audio Copy, is the best for ripping CDs.
It might not be the easiest to learn, but once you get to grips with it you will not look back!

www.exactaudiocopy.de

[Jason]

Can listening to VBR mp3's on your mp3 player make the batteries run out faster than if you were listening to CBR mp3's?

Jason

[vinnie97]

in a word, yes.

[FlameGrilled]

In a set of words, yes no and maybe.

Although not scientifically conclusively tested (i really dont have that kinda time to spare), over time you do draw the following conclusions :-

Codecs require different loads on the on-board cpu duirng the decode process - and this can affect (shorten) the running time on one charge when the decode is very intensive (this, combined with less than optimal coding that can occur in firmware designs has been borne out beta beta ogg supporting editions of the iFP firmware). Clearly, from that, you can also stand to find that a very low-demand decode action (i.e. low impact on the CPU) can also make for better running time on the player.

i dont know, in practise, which of MP3 or WMA/ASF is better in terms of cpu load when decoding, but i suspect that WMA (and it's tendency to perform at lower bitrates) would probably creep ahead.

Ogg tends to be a bit of a CPU hog at present, as born out by the 50% reduction some people are getting with their lovely otherwise long-life iFP decks with the beta firmware - the iMP-550 has got some beta Ogg supporting firmware too at the moment, so that's open to adding more fuel to the discussion.

By comparision, although not tested yet in a portable device with the usual poorer CPU resources, MPC is said to be better on the CPU load respect due to lower decode complexity. AAC, on that account, is a question mark still but iPod owners would be in a good postition to assess that one on a MP3 vs AAC ratio on how it affects battery life.

Please note, the Ogg firmware mentioned above is beta, and therefore less than optimal - the iHP firmware (supporting Ogg) is a better benchmark to use for efficiency in terms of the decoder at present.

To an extent, exactly how much i haven't had time or the inclination to explore wholesale, the smart money move for getting the most out of the battery endurance per charge, is to encode with emphasis on letting the encoder make use of the lower bit-rates where possible. This is why, simply, despite WMA not being overly loved by people - WMA users (who often work with a 48-128K bitrate range) see some of the best running times out of their iRiver decks.

Equally, in the mp3 arena, the load MP3 decoding puts on the CPU can be reduced by using MP3PRO format to encode to. This is optimised around the use of lower bit-rates where possible. Note, encoding to MP3PRO only gets you encodings that are more bitrate friendly and smaller in resulting size, since no iRiver deck acutally decodes MP3PRO natively, it treats them as Mpeg 2/Mpeg 2.5 Layer 3 encodings and disregards all the SBR data contained in the files.

How often the player has to read the disc, how frequently and how long the drive is running for 'under load' (i.e. powered) also has a shortening effect on running time. A substantial part of how iRiver got their once class-leading battery endurance on their iMP series is down to the fact the disc isn't being spun when it needn't be - unlike 1st gen MP3 which mimick 1st/2nd gen audio cdp's by keeping the disc spinning frequently or continously.

Every time the disc has to be re-read or re-scanned due to a read problem, as this is an on-load power consumption, will add to the decline of the battery endurance.

So, in this respect, ensuring that your CD-ROM burning is done comfortably on the safe side of the rating of the media and burner is a sound move - where creating a bombproof burn goes, taking a little extra time and avoiding the burner having to invoke it's 'smart burn' error correction is definately in your favour.

I can honestly conclude, from working with a few iMP's and an iFP and also an aging CL DAP Jukebox and short term use of ATRAC3/ATRAC3 Plus (using a Sony D-NE1 ATRAC CD Walkman) that my conclusions about disc access/media, trying to keep bit-rates low where poss and the issues where avoiding high complexity decode operations and working with low-complexity codecs all helps you see the better part of the quoted official battery performance that iRiver published - and lets face it, in all instances of published formal figures, they are prospective and/or best case scenario ones.

That said, 75%-85% of the quoted official battery performance is easy to get - you just gotta screw yer head on tight and apply the grey matter - and therefore make life easier on that poor overworked iMP :P

FG

[vinnie97]

Ah, of course, the bitrate range will also make a difference, but VBR decoders put more overhead on the CPU than their CBR counterparts, surely (generally speaking).

[alexanderino]

Originally Posted by Evil Eivind

My main priority is to get the best sound, and loosing as little as possible in the ripping process, and compression (file size) comes second -- if file size wasn't also an important factor, I'd simply use WAV files.

So what settings should be used in order to get the best results, preferably with as good sound as the original CD, and with a decent file size?

You want --alt-preset standard. It is highly optimised to sound as good as the original, while minimising size. Most people cannot identify originals from --aps MP3s in double-blind tests.

If filesize is not an issue, then choose --alt-preset insane instead of --alt-preset standard. Your files will be encoded at 320 kbps CBR, about 55% bigger than --aps, but it will be as good as MP3 gets. Most people cannot differentiate between it and --alt-preset standard, let alone the original.

I've actually seen that guide before. What I don't like about that particular guide is that it only tells you what to do, not why you should do it, nor does it point out the pros and cons of using the method it presents - nor on any other methods, for that matter.

My CDex guide (new link) is aimed at beginners, and most do not want to know the reasons behind the settings If you have a query, post it here and I'll help you out.

Cheers,
Jason

[NPswimdude500]

i've been using lame 1.32, 3.97 (alpha)

[alexanderino]

Originally Posted by NPswimdude500

i've been using lame 1.32, 3.97 (alpha)

Don't use the 3.97 alpha versions for anything serious! Recent tests conducted at Hydrogen Audio indicate that the latest LAME is worse than 3.90.3 in quite a few cases.

I will not recommend newer versions of LAME until they are demonstrably superior than 3.90.3.

-- Jason

[DreamTactix291]

Originally Posted by vinnie97

Ah, of course, the bitrate range will also make a difference, but VBR decoders put more overhead on the CPU than their CBR counterparts, surely (generally speaking).

Not really. It doesn't take any more CPU to read a different 4 bit sequence every frame than it does to read the same 4 bit sequence every frame.

And also I'd really recommend aps to people wanting to make mp3s but I don't like shoving it down people's throats.