Guide to Ripping & Encoding High Quality MP3s
 

- First, decide which audio codec you wish to use!

• MP3 is the most popular format, the most supported, and therefore the first choice for most people. In recent years, the quality of MP3 has been continually pushed to the envelope by the LAME encoder team (yes, it really is called LAME) despite the limits of this aging format. Sometimes, however, the limits cannot be easily overcome. For example, LAME attempts to fix the gap problem, where MP3s typically play an extra bit of silence at the end, something quite noticable when playing tracks that are supposed to flow into the next. Since LAME's fix is not a part of the MP3 standard, however, only a few players will skip that trailing silence.
  PC & HARDWARE PLAYERS: nearly any
  
  
• Ogg Vorbis is an unpatented, open-source, free-as-in-freedom audio codec. It especially excels at low bitrates (less than 128Kbps) compared to the other formats, and it is gapless between tracks. Although official development has crawled along, unofficial Aoyumi's Tuned Vorbis (aoTuV) versions have kept quality marching forward. Also of note, some claim that Vorbis encoding flaws sound less harsh than those of MP3. A fair number of hardware players support Vorbis, but unfortunately not nearly as many as MP3.
  HARDWARE PLAYERS: iPods (with Rockbox), several iRiver models, serveral Cowon models, Pocket PCs (with TCPMP), and many others
  PC PLAYERS: WinAmp, Windows Media Player (w/filter), Foobar2000, and many others
  
  
• FLAC is not a lossy codec like all of the above. Instead, it performs lossless compression, which means FLACs will always output the exact same audio that was put into them. But because FLAC does not selectively discard data like lossy formats, the files are quite larger. However, decoding takes very little CPU power, which makes for fast conversions from FLAC to whatever lossy format your portables may use, or whatever format would be easiest to "share". FLAC is useful for archiving in perfect quality, or for those with huge hard drives.
  HARDWARE PLAYERS: iPods and iRivers (with Rockbox), Pocket PCs (with TCPMP), and others
  PC PLAYERS: WinAmp, Windows Media Player (w/filters), Foobar2000, and others

I. First-time setup:

1) Because reading the CD right matters just as much as how you encode it, download & install the best, Exact Audio Copy, from
Introduction Exact Audio Copy

2) Download the currently recommended encoder for your preferred format, unzip, and place it in a folder you will remember.

MP3: LAME 3.98.2
Ogg Vorbis: Oggenc2.85 using aoTuVb5.7
FLAC: FLAC for Windows with installer (v1.2.1)

3) Run Exact Audio Copy. The Configuration Wizard should pop up (if not, start it from the "EAC" menu).

• When it asks you, select all your CD drives. (Note: CD-RW drives are typically best for ripping purposes.)
• Select "I prefer to have accurate results" for each drive.
• Auto-detect your CD drive features. This requires an audio CD to be in your drive.
• MP3 only: Check "Install & configure the external LAME.EXE compressor." Stop the search, manually find the path where you downloaded LAME, and select either quality option given (this will be changed later).
• Enter the e-mail address.
• Select "I am an expert."

4) Open the "EAC Options" from the "EAC" menu.

• Under the Extraction tab, put "Error recovery quality" at "Medium".
• If you have a constantly-on Internet connection, under the General tab select "On unknown CDs, automatically access online freedb database."
• Under the Filename tab, change the naming scheme to
  Code:

  ---

  %N - %T

  ---

  which is basically the format "01 - TrackOneName". You may want to put additional parameters in there too, that's fine, but make sure the track number gets in there somewhere... unless you feel like having the tracks listed in alphabetical order rather than the natural CD order. :worried:
  You can also put your albums in directories, for example
  Code:

  ---

  %A\%C\%N - %T

  ---

  which is "\Artist\Album\01 - TrackOneName"

5) Open the "Drive Options" from the "EAC" menu.

• Under the Extraction Method tab, it should already be set to "Secure mode with following drive features." If not, change it.
• Under the Drive tab, hit the "Auto-detect read command now" button.

6) Open the "Compressor Options" from the "EAC" menu.

• Under the External Compression tab, change the "Parameter passing scheme" to "User defined encoder", and enter the appropriate file extension below.
  
  MP3: .mp3
  Ogg Vorbis: .ogg
  FLAC: .flac
  
  (Note: Selecting "User defined encoder" disables the effects of the "high quality/low quality" buttons & the bit rate drop-down menu. So just ignore them.)
  
  
• Browse to the location where you unzipped the encoder. The specific file you're looking for is:
  
  MP3: lame.exe
  Ogg Vorbis: oggenc2.exe
  FLAC: flac.exe (in the "bin" sub-folder)
  
  
• Enter under "Additional command line options":
  (These commands determine what methods will be used to encode the audio)
  
  MP3
  Code:

  ---

  -V 2 --vbr-new %s %d

  ---

  Ogg Vorbis
  Code:

  ---

  -q 5.0 -a "%a" -t "%t" -l "%g" -d "%y" -N "%n" -G "%m" %s %d

  ---

  FLAC
  Code:

  ---

  -6 -V -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s %d

  ---

  NOTE: Make sure no extra spaces or discrepancies are included when you enter or copy these commands! This can cause the encoder to fail when it tries to encode the music, and you will just end up with WAV files!
  
• You will probably want to check "Delete WAV after compression". UNcheck "Add ID3 tag" if you are NOT using MP3.
  
• MP3 only: Check "Add ID3 tag." Under the Offset tab, look at "Construction of the ID3 tag comment field", select "Write following text into ID3 tag comment", and then type LAME v3.98 -V 2 --vbr-new or your version of LAME & encoding method used, if different. (This is simply used for identification, so anyone viewing the ID3 comment can tell what quality mode was used to encode the MP3.)
  NOTE: Do NOT also add ID3 tags via the "Additional command line options", or you will end up with possibly-erroneous double-tagged MP3s!

Congrats, you finished the long part! Once everything has been set up, you shouldn't need to go back & mess with any of these settings. =)

II. Ripping each CD:

• Run Exact Audio Copy & put the audio CD in the appropriate drive.
• Either enter the CD/track/artist info yourself, or get it auto-filled from the CDDB (ALT-G) if you're connected to the Internet.
• To rip & encode the entire CD, click the "MP3" button on the left. To get individual tracks, select all the ones you want and press SHIFT-F6.
• If you don't mind taking double the time to be even more confident that your rips are coming out perfectly, then instead of hitting the MP3 button, right-click on the selected tracks and select "Test & Copy Compressed". After all the ripping, if the "CRC" field at the very right says "OK" for each track, all is good! If not, the test & actual copies read differently, which means one or both read something wrong.

That's it. The End! Hopefully you now have a folder full of high quality audio files ready for listening!


A lossy file (such as MP3, AAC, or Vorbis) can never turn itself back into the original audio it is trying to approximate. Any converting, any burning, and any playing can only use the imperfect audio in that lossy file to do its job, so turning an MP3 to a WAV or burning it to a CD will only result in audio that sounds exactly as imperfect as the MP3. Also, if you were to take that imperfect-sounding WAV and turn it into MP3 again, it will only result in more loss. For this reason, it is inadvisable to convert lossy files to other lossy files. It is always best to use lossy compression on only original full quality audio.

Since lossy compression works by trying to remove the information humans percieve least, such quality degredation may not always be detectable. Indeed, the hope is that the encoded audio will sound exactly the same as the source. But quality reduction does always occur even if it is often inaudible.



I. First-time setup:

• Foobar2000 has a reputation as a spartan, utilitarian little audio player. However, it features one of most customizable file converters that I have yet to try. So go ahead and get downloadin' and installin'. Oh, and make sure not to de-select that important little "Converter" component.
  
• Download the currently recommended encoder for your preferred format, unzip, and place it in a folder you will remember.
  
  MP3: LAME 3.98.2
  Ogg Vorbis: Oggenc2.83 using aoTuVb5.7
  FLAC: FLAC for Windows with installer (v1.2.1)
  
  (Wait! Haven't you done this part already? If not, return to the top of the thread, do not pass Go, do not collect $100, and install EAC already!)
• Run Foobar2000 and add to the playlist the file(s) you want to convert. Select them all and right click, choosing "Convert > ..." from the menu.
• Choose your preferred audio format from the drop-down box under "Output format". The default encoding settings are right in line with the suggestions of this guide, so there should be no need to tweak them. If you do wish to tweak them, however, you can hit the "..." button to the right.
• Under the "Output files" section, you can edit the output file names. I would recommend changing the Name Format setting to %filename% so that your converted file will only differ in file extension.
• Under "Output path", tell it where you want to put the files. Then click "OK" at the bottom. Now remember when I told you that you had to memorize where you put the encoder? This is where you have to go find it, Fido.
• After selecting the directory to drop the new file into and watching the progress bars fill to full, you should now be the proud owner of a newly converted file, complete with any tag information that was in the original file.

II. Each subsequent conversion:

• Run Foobar and add the files to the playlist.
• Select, right-click, "Convert > ..."
• Select your desired codec, if it isn't selected already, and hit "OK".
• Wait for moist, delicious cake^Z^Z^Z^Z MP3s.

Foobar2000, especially with all of its components, can convert just about anything you throw at it, to just about any format you want.
Except for emulated game music. For that, just download some a WinAmp plugin and diskwrite it to WAV before throwing it to Foobar.





MP3Gain

MP3gain is a very useful program that performs volume normalizing, maximizing, and adjustment. Since MP3s are just an approximation of the original file, and since modern CDs are pushed so very close to the maximum volume/amplitude value, at some points the waveform of a decoded/played-back MP3 may calculate as a value above that maximum. This is called clipping, because those higher values must be truncated down to the maximum limit, flattening those segments of the waveform and often introducing annoying pops or static. MP3gain can prevent clipping by reducing the MP3's internal volume level just enough that its peaks will not breach the maximum amplitude.

The program can also "normalize" song loudness, meaning that it will make MP3s sound about equally loud from track to track (in default Track Mode), preventing the constant need to adjust your player's volume when listening to your collection. MP3Gain will even preserve the intended volume differences between songs on the same CD when you use Album Gain mode, instead attempting to equalize the overall loudness of different albums.

Note that for this to work as intended, you must Album Gain or Track Gain all the MP3s in your collection. Also, it will often make your songs quieter. This is because it uses a loudness standard that attempts to minimize the amount of clipping caused by raising dynamic tracks, with high peaks and otherwise low levels, to the same overall volume as more modern tracks, which tend to be so dynamically-compressed that the entire song hugs the maximum amplitude.

NOTE: Winamp has recently gained the ability to read MP3Gain's ReplayGain tags, so the compatability worries previously espoused here are now irrelevant.


Scientific Lossy Audio Codec Comparisons

- Sebastian's Public Listening Tests
- Roberto's Public Listening Tests

Please let me know if there are any other links I should include.






Why is it ripping so slowly? I can get 5-10x faster with MusicMatch/CDex/WinAmp/etc!

• Secure Mode double-reads the CD to make sure there was no read error (i.e. each data sector should be the same when read twice) caused by something on the CD or just a bad CD drive. This is the only mode that can let you know when there is an error, and the only one that will rescan the CD to get a prominent reading when it does find a discrepancy. Speed is what you sacrifice for this quality.
• If you absolutely hate the slower ripping speed, or find that a CD is encountering error after error & taking hours, use Burst Mode with Test & Copy to verify. Occasionally Burst Mode results in a better rip in those cases.

I hate VBR mp3s! They always give me problems, and are certainly not high quality!

• LAME's implementation of VBR (variable bitrate) is markedly improved over any other VBR mp3s you've heard. Audiophile enthusiasts have even done scientific double-blind listening tests to prove that LAME's VBR is audibly "transparent" (sounds no different than the original audio) to most listeners.

What's wrong with 128Kbps? Why use something so LAME? (harharhar) Why not encode with a constant 192Kbps?

• Firstly, if you can't tell the difference between 128Kbps mp3s and the originals, do yourself a long overdue favor: buy yourself a better set of speakers, headphones, or sound card. (Remember that the weakest links in the chain from that audio file to your ears dictate the sound quality.) However, older folks and those with hearing loss may not be able to tell the difference. And honestly, the difference can sometimes be subtle.
• We use the LAME encoder, as it is considered the best encoder out there for bitrates above 112Kbps. LAME produces better quality mp3s than even the official Fraunhoffer encoders. Isn't it great that LAME is free? :D
• The -V switch invokes a VBR (variable bitrate) encoding mode in LAME. VBR is, in theory, inherently superior to CBR (constant bitrate). CBR mp3s may at times have too few bits available to encode all the audible information in a frame. Or one frame may only need a fractional amount of the available bits to be audibly the same, with the rest of the frame filled with inaudible data to keep the mp3 at a constant bitrate. A variable bitrate cures such problems of lost audio quality & wasted file space by determining how many bits should be used in each different frame to keep the audio audibly unchanged. (Admittedly, the "bit reservoir" in CBR mp3s attempts to resolve this as well, but it is much less effective than pure VBR.) Typically, a VBR file may possess audio quality equivalent to a 10-20% larger CBR file.

What are the typical average bitrates of MP3s using these VBR switches?

• See the LAME VBR bitrate chart on the Hydrogen Audio Wiki.

Why is the encoder set to "User defined encoder" in EAC, when there is already an option for the LAME encoder?

• Choosing "User defined encoder" and entering -V [0/1/2/3/etc] --vbr-new %s %d effectively disables all other mp3 encoding options in the External Compression tab. This is done because certain quality parameters in LAME can interfere with -V's functionality, even some typically associated with producing hi-quality LAME mp3s. We are merely making sure that these specific VBR quality settings, and the source & destination files, are the only parameters passed to LAME.

Why set Error Recovery to Medium? Why use Secure Mode?

• If any kind of error occurs while reading the CD, an Error Recovery of Medium tells EAC to rescan this section of the disc the 2nd-most number of times allowed. EAC will then use the most prominent result found from these reads. ('High' was previously recommended. But if a 'Medium' amount of reads isn't able to give a prominent result, more attempts will very likely be little help & will only slow the ripping process.)
• The Burst & Fast modes may often make copying errors without realizing this or attempting to make any sort of correction. Secure Mode does rip more slowly, but it attempts to make a more perfect copy of the track than either other mode.

Where can I get more information about digital audio?

• The Hydrogen Audio forums are an excellent resource for digital audio discussion, explanation, testing, and development.

Why is this post so long?

• Because it's awesome?? :sweat: :worried:

If you have any questions about all of this, feel absolutely free to reply or contact me.

Oh wow, this is a huge upgrade of my current ripping standards. Thanks a lot for this moguta.


(I think I still follow your old ripping guide.. the one made a few years ago.. like 3 or 4 years ago.)

I recently use -V 0 though...... Does it make me a bad person? ;_;

Nope. It's totally up to you whether the increase in sound quality is worth the increase in bitrate or not.

Thanks to Darko for keeping a copy of my thread alive even after the GFF crash! This one has a few changes, such as a totally new section on encoding files already on the hard disk, additional explanation of what MP3Gain does, updated broken links, a short mention of some CPU-optimized Vorbis encoders (much quicker!), and the newest version of the Musepack encoder. Oh yeah, and taking out AAC to reduce clutter, and because I have the feeling absolutely no one who followed my guide used that format.

cubed, I would argue that -V 0 --vbr-new is a bit overdoing it & wasteful of space, since -V 2 --vbr-new doesn't reveal even subtly audible difference in the great majority of cases. But at least you're not using 320Kbps. :p
*Coughs to clear his throat and dons his mock-superior voice* Yes, cubed, you are a very bad man for using higher quality settings than necessary for your own personal use! Shame, to the highest degree! ;)

Welcome back to keeping our ripping in line! I'm going to update my settings now.

Also, hi. ^_^

And I'm stickying the thread. FIRST OFFICIAL MOD ACTION IN 4ish YEARS. WOO.

Omigosh it's Drexie! And I get the honor of having my thread stickied by him!

Oh, yes, and hello. ;D

Ah, who cares if it's your first action in four years? Wouldn't want you to break out into a sweat with all that heavy mod work. Nope, nope! :D
Good to see ya around again.

Thanks for this, this guide is highly useful.

Quick question, I would like to use EAC to compress WAV's and decompress MP3's.

The problem is that under EAC -> Compression Options -> Offset, the "use lame command line encoder/decoder for decoding mp3 files" is grayed out.

Anyone have any ideas on what the problem is? Thanks!

Phatcorns, I'm not certain why that is. The option is ghosted on mine as well...

But, if you are using lame.exe in the "External Compression" tab, following the directions in my ripping guide, then it will use those settings when doing the "Compress WAVs" command. And I believe EAC may be able to decode MP3s without LAME.

Additional Post:
And just linking a post I just made in another thread which explains, in a bit of detail, some of the aspects and trivialities of audio encoding. For those who care to know...
http://www.gamingforce.com/forums/be...ost355440.html

So, for some odd reason, lame.exe is not included in the bundle of files provided by LAME's website. That, and the link you have provided for LAME is also down. Any thoughts on the matter?

Additional Spam:
Nevermind. Take an extra five seconds and refine a Google search will get me what I need.

Sorry, Aevum. Evidently Rarewares.org -- the site I link to for the LAME encoder -- was down for a bit due to a billing dispute. But it's back up again.

The track/artist/#/etc doesn't seem to work when ripping in MPC. EAC actually names the artist, for instance, '%a'.

Hrm, Cal, that is very odd. EAC should be converting those symbols (like %a) into the actual artist/album/track/etc. strings shown in the main window before it passes the command to the encoder. Perhaps you could try it without the surrounding "quotes"?

EDIT: I just tried to reproduce your problem, but to no avail. Even with the ""s around the symbols, the tags were written fine. :(

Is there any way I get get EAC to append APE and not ID3?

Apparently it's the opposite case with Musepack.

I'm not exactly sure what you mean by that, Cal.

EAC and Musepack work together fine for me under these compression settings (and with the rest of the commandline that's off-screen, identical to what I wrote in the guide above).

http://i24.photobucket.com/albums/c2...es/EAC_MPC.jpg

Hey, I've used your guide for ripping in the past, but I recently reinstalled Exact Audio Copy and LAME and followed the procedure again. This time, I'm encountering problems. I go to rip, and everything seems to be going fine through Exact Audio Copy, but the LAME encoder isn't converting all the files to MP3. It does many of them, but what I am left with is a partially ripped CD. I know it might be hard to pinpoint, but I was wondering if you might know what the problem would be.

Hrm.... Rocktime, see the screenshot in my last post? Check-mark "Check for external programs return code" at the bottom left. Then, when any error dialog box pops up during extraction, save a screenshot of it. Hopefully we can figure out what the problem is that way.

Alright, So, I go to rip the CD, I believe I have followed all the instructions as described above. The first 3 tracks go fine, the fourth track is copied OK by EAC, but when it goes to compress I get the error shown in this attachment. The rest of the CD goes fine after OKing the error, except the same thing happens with the final track. This time, I tried going back and having it retry only the missed tracks, and it was able to copy and compress them sucessfully, so I guess my problem isn't so much of a major issue as an inconvience.

Though, the previous time I tried ripping this CD it failed on more than half the tracks, and several other CDs had the same issues.

That's really weird. Especially so with you saying that it won't work sometimes, and then sometimes those exact same tracks will encode. o.O

I don't understand that at all. Even if EAC was getting different rip results each time... the audio itself shouldn't make LAME error. Only, like, invalid parameters or such... and EAC should be passing LAME the exact same parameters each time.

The only thing I can possibly think of is LAME having trouble with the temporary file names, since that's the only thing that changes each time. Perhaps the ()s in the temp file name that you linked? Although, really, I can't think of why that would be any problem.

For some reason, the files are doing some funny things.

I ripped the audio off of a DVD. In Adobe Audition 2.0, I split the tracks up, did the fading and touching up, and kept the original WAV file. One of files, for example, has a length of 13:10. When I listen to it, it ends right on time! Hooray! Time to get it to a more convenient format.

Doing everything above, I produced the MP3s. But when listening and verifying they sound right, something's off. The length STILL says 13:10, however, it goes over that and ends a few seconds after it. It sounds exactly the same, though, but it's almost as if during the course of the song it managed to lengthen itself somehow. I also tried burning the WAV files onto an Image and ripping the image through EAC with the same result.

I was using the recommended LAME VBR command line and still, for some reason, get odd results. Any known reasons why?

Edit: I tried the CBR of 320 (-b 320), which also produced 13:10, but it ended at the right time. Seems there's a problem with my computer handling the VBR.

What application are you using to play MP3s? Winamp shouldn't have this problem, nor should Foobar2000. Yet it wouldn't surprise me at all if Windows Media Player messed it up; past versions have handled VBR files rather shoddily.

It is WMP, actually, I'll try it out in other programs (should of did that in the first place, I assumed it was a bad encoding).

Hmm, does seem to work better now. It sounds exactly the same, don't know why it does that.

There's nothing about mpeg4 files!! How Do I convert them ? Is there a freeware that does it?

thx

Glad to hear you figured out that it's the player (it figures, I've never liked WMP), rather than the MP3. If you're not using the latest version, perhaps updating could help.

There is no one specific MPEG-4 audio specification, but instead there are a number of versions of AAC. I removed the AAC encoding from my guide because the only encoder that works with Exact Audio Copy produces notably worse quality than the Apple, Quicktime, and Nero AAC encoders.

Check this out, folks:
http://www.hydrogenaudio.org/forums/...howtopic=54085

Everyone using V2 as a standard yet? ;)

- Spike

I can't see what you're trying to say.

If it's that LAME (including its -V2 setting) is a good codec like it was discussed not so long ago and that is actually mentioned in the first post of this thread, sure, I agree. If it's that you actually want to discuss about LAME's settings/presets (and in answer to your question at HA), -V2 is not the best VBR setting to reach the highest quality, technically. However, it is considered to be transparent by the majority, so the advantage of using it over higher settings like -V0 is that it will make the filesize smaller while still having a "perfect" quality (in relation to transparency). I guess some people have better ears and they find the sound is bad with -V2 (which surprises me!) and they prefer to go with -V1 or -V0, but in my opinion, the quality difference is so small that I'm not certain if it's actually worth it. At that point, switching to another format would be better, if extremely-high quality is the objective.

This thread has been recommending -V 2 for quite some time now... in fact, ever since the --preset/--alt-preset modes were abandoned to introduce the -V switch.

I'm not too sure what new you're trying to point out here.

Nothing, I just find the sort of relative complexity of MP3 encoding amusing.

I'm also relieved to find a good standard that everyone can easily use, without ridiculous custom switches.

But I guess what I was hinting at was, is everyone using this standard and does everyone understand it :) I'm guessing not.

Regards,
- Spike

I think I remember a time where #gamemp3s used to encode their CD rips in -V 2, but they switched to -V 1/-V 0 some time ago. I've always encoded my music projects in -V 2 and I'll keep it that way for a while (hell, I think this very thread was where I got the command line from and I've been using it since late 2005).

Well, it is a highly mathematical process with so many possible implementations.

Hehe, no and no. I mean, you just linked that HA thread... and its only one of many more like it. People in that forum get rather tired of all the "newfangled" command line combinations that newbies come up with and try to claim as THE BEST! :p

V1 and V0 is pretty impressive, although even by my standards it sounds like overkill.

Well, I know that, but what I mean is for such a widely used format, it's taken until now to come up with easy to encode high quality MP3's. Most people don't understand VBR, let alone alt preset whatever.


Yeah, I tried to ignore that stuff. Not very useful :)

So, V2's the recommended standard, that's good to hear.

I'm also glad you've put time into working on this, Moguta :)

- Spike

An update:

The latest version of LAME is LAME 3.98b3, and a very easy to use (not command line) interface is LAMEDrop, which can be found here (at the newly designed Rarewares.org page):

http://www.rarewares.org/mp3-lamedrop.php

If you're anal and *must* use a "100% stable" program, there's a 3.97 version as well. But people wouldn't release public beta's and keep updating them if they were worse (hint: 3.98b3 = best MP3 encoder out there).

So all you people using old MP3 encoders (before 3.97), grab LAMEDrop today, it's as easy as you can imagine!

- Spike

Then, using your logic, because there's an update out there with a higher version number, by that fact alone it must be better than all versions that came before it? Have you ever heard of "version regression"? For example, LAME 3.90 had been recommended as the preferred version over LAME 3.93 because of a regression in quality. And numerous programs have had flaws introduced, or re-introduced, in successive versions. It's pretty much an inevitable part of developing complex, and even sometimes simple, programs.

And when we're talking about perceptive audio encoders, something so difficult to objectively evaluate, where the "better"-ness of a program is based on how it sounds to the human ear, something not measurable by a computer nor even easily objectified by humans themselves, it needs thorough testing to ensure that the changes introduced have indeed improved the overall quality.

Thank you for the news of the new 3rd beta of 3.98, but as of now, 3.97 stable remains the recommended version of LAME both at HydrogenAudio and in this guide.
Also, thanks for letting us know about the RareWares site redesign. It seems I will need to update the links in my first post.

I'm getting a weird error from EAC. I recently installed it on my work computer (currently posting from it), and this is what I get when I try to compress it:

http://img413.imageshack.us/img413/9606/untitlednq5.jpg

(I know image quality sucks... don't have photoshop on this computer!). It looks similar to the other person's error on the first page. I still have all the wav files when I ripped the CDs. Any suggestions?

Judging from the command line it's attempting to pass, it appears that you have your Parameter Passing Scheme ("EAC" menu -> Compression Options -> External Compression tab) set to "LAME MP3 Encoder". It should be set to "User Defined Encoder", at the very bottom of the list.

Hope that helps! :)

Moguta:

I take your point man. I'm going to be using b4 because it has advantages over 3.97, and I use high bitrates (apparently there's no issues with b3/4 at high bitrates).

And Moguta- maybe you should consider recommending LAMEDrop, not command line utilities. Then noone is using switches, everyone's using a simple to follow VBR method and it's easy to explain to newbies.

Don't forget, Wiki's at HA are quite often out of date :) People have lives.
For example, the recommended Vorbis encoder is an inferior encoder to the best (stable I might add) one out there (it's not even on RareWares!).

No problem man, we're ultimately in agreement I think. <offers hand to shake>

- Spike

I'm not sure "no issues" is quite accurate. All lossy codecs tend to have audio issues, and I did see some early comparisons in a HA thread where it seemed that 3.98 improved the handling of some problem samples and receded in others. Although, it's probably true that there are no major, glaring issues.

That might be a good idea, at least for those who want to only encode from WAV. I've just never liked the *drop interface (no menu or buttons?), and some may find transcoding useful. But I'll consider.

o.O I'm not sure what you mean by that. I thought AoTuV beta5 was the latest Vorbis, unless you're referring to all the chipset-optimized compiles.

I think so, too. No hard feelings here. *Shakels*

Anyone upgrade to the latest version of Exact Audio Copy, V0.99 prebeta1? Wondering if it's worth upgrading to...

http://www.hydrogenaudio.org/forums/...howtopic=55852
Here's the list of new features, although most people probably don't need to worry about them. The addition of AccurateRip, however, is a quick additional method to ensure the security of your rips.

You'll also notice some bug reports in the topic I just listed, although seemingly only with a couple of the new features. Personally, I'd advise waiting just a little while, until bugs can be found and ironed out.

That's what I plan on doing, but do want to try out AccurateRip and couldn't figure out how to set it up with the last release... ;)

Oh well, I already have two different versions of EAC installed, I can wait!

Yeah, I'm going to get a new EAC pretty soon :)
Gotta love that proggie.

By "no issues" I meant no problems compared to 'stable' 3.97, not that it's lossless or anything :P


The early comparisons relate to 3.98a, if I'm not mistaken, or older 3.98b versions.

At high VBR bitrates (which we should use as the norm), 3.98b4 is a better encoder. But it's not really worth changing the recommended version until the next stable one comes out, I agree.

Why do you need buttons?
And, all the menu's can be accessed by right-clicking the program once opened.


I think it's much easier for the average user (I use it :) ), plus, it's easier to get good quality music out of it- no silly custom switches or nonsense like that, you select a bitrate (e.g. 220) and VBR and away you go (as well as tagging options where appropriate, etc).


Hehe, pepoluan from HA upgraded the Wiki after I wrote that post (not because of me, there was a debate on HA subsequently and coincidentally). b5 is now recommended. At the time of posting they were recommending 4.51.


Thanks for the shake!

- Spike

Hey, just wanted to offer my thanks for this fantastic guide! I used a similar one from the GFF forums several years ago... Now I can only wince when people rip with Windows Media Player. Sure it's fast, but it's also crap ;)

Thanks for the compliment, and I'm glad you find this guide useful. And, if you'll notice, the very first thing in the guide is "new news" from 2005... so the similar guide you speak of having used is probably a previous version of this one. :)

While some people -- the mentioned Windows Media Player users included -- may not care much for the quality of their sound as long as notes and voices can be heard, I'm always eager to help those who wish to preserve and revel in every small aural detail of their music!

Here's a little history: When I first started encoding to VBR from lossless sources, I used Lame 3.90.3 with the APS (Alt Preset Standard) preset then I switched to Lame 3.97 and used the V2 preset (not --vbr-new) which I believe is the same as APS. Now I've been using this encoding setup for some time (around a year) and I've had no complaints with it.

However, I've been hearing that --vbr-new is recommended over normal vbr. I recently encoded 2 MP3s (of the same song) one with the normal vbr preset and the other with the --vbr-new preset and I've haven't noticed any difference in quality at all, just that --vbr-new is a little faster when encoding.

I've also heard that artefacts are more worse with --vbr-new then normal vbr but some sources say that --vbr-new is better quality overall than normal vbr.

So, I was wondering, should I make the switch to --vbr-new?

Hydrogen Audio currently recommends --vbr-new because of the noticably quicker encode speed and because in their listening tests, quality generally either slightly improved or was no noticeably different. I'd say go right ahead.

please, could someone tell the equivalent supa-high quality audio settings (windows, LAME, conversion from CUE (FLAC or APE) to tagged mp3's) for

foobar2000?

i have only foobar2000, no other tools.

Sure. Using the latest version of foobar2000 (0.9.4.5), open the Preferences tree under the File menu.
Find and click Converter, directly under Tools.
Check the existing Encoding Presets for the text MP3 (LAME) | 190Kbps | V2, fast.
If it already exists, use that and skip the next step.
If not, click Add New, select the MP3 (LAME) encoder from the drop-down, move the quality slider to ~190Kbps (*) V2, and activate Fast Mode (--vbr-new).

Now, whenever you right-click and Convert your music, select MP3 (LAME), 190Kbps, V2, fast from the drop-down, make sure ReplayGain Processing and DSP Processing are OFF, and let it start chuggin' away!

Hello Moguta,

is the LAME V2 better than LAME CBR 192? Many/Most files which i encoded with LAME V2 have an average bitrate of ~160; only few reach an average of 190+. So those 160-VBR's, are they indeed better than a potential CD-rip to 192-CBR?

192-CBR (=average is 192) is higher than ~160 (=average is 160). Isnt higher better? That's why i am asking..

Thanks, best, Lousy

VBR modes are better tuned in general. There is no extensive work done on the CBR encoding modes, simply because encoding in CBR is deprecated anyway. You don't use CBR if you don't have to.
If you want to gain maximum quality use VBR V0.

You still have the option to use a freeformat stream encoding, allowing bitrates above 320kbit/s - but as I stated in several other threads: the MP3 encoding algorithms has some flaws by design, flaws that won't go away by simply increasing the bitrate. It's the way MP3 was designed and VBR V0 takes it too the limit by balacing filesize and encoding quality.

If you want more quality change the encoding format to something like Ogg Vorbis or AAC. If you want to stay with MP3 and use a modern/recent audio playing device -> use VBR V0

Higher bitrates means that more information is being stored. However, whether a particular higher bitrate is "better" is not an easy question to answer.

The short answer is that the ~32Kbps difference between your -V2 --vbr-new and 192Kbps CBR encodes is very likely a combination of CBR inefficiencies and inaudible information.

The entire point of MP3 is to shrink file sizes. VBR attempts to be as efficient about that goal as possible, by determining what bitrates are necessary for each file to encode them with a certain -V quality. More complex audio requires fewer bits, and less complex audio really doesn't need high bitrates (Note: Though true, that explanation is an extreme simplification). CBR, in contrast, just throws however many bits at a file that you tell it, without regard to how many it actually needs to sound the same as the original. It could be too little, or -- as it seems in your example above -- too much.

By the way, I would stick with -V2. It is a time- and test-proven quality setting. The VBR quality #s above that (-V1 and -V0) will likely begin to store more inaudible, unnecessary information, eroding the VBR's efficiency. Some people do prefer the "overhead", however, feeling safer even if there is no audible difference.

Wow, great explanations. I'm enlightened. Thanks for the splendid replies!
Ah, me too i have a foobar related question... Does a plugin (component) exist for converting to Windows Media Audio (*.wma) instead of to LAME V2 (*.mp3)?
Some of my sets and rips are in *.wma, so i would want to convert the inet ape/flac's to wma ... just for the sake of homogenity of file extensions *g*
i googled. and i think that foobar2000 doesnt support the conversion TO wma.

You don't want to convert to WMA, trust me...

I'm not sure if this is the right place for this question, but I've recently ripped some game music into .AUS format. How can I convert .AUS files into WAV or MP3 files? Thanks!

Thanks. I could even go more in-depth, but I figured I'd spare you the long-winded explanation. ;p

And although I would recommend encoding to LAME MP3 rather than WMA, I did find a guide to do exactly what you ask:
How to set up Converter for WMA 9 - Hydrogenaudio Forums

I'm sorry, but I don't know what .AUS files are and couldn't find it in a quick Google. :(

that's exactly what i was searching for (even on that forum) but never detected in the WWW. you got the better nose and eyes :cool: Thanks for your kind help. I've saved that page to HDD, downloaded the specific encoder, and will follow the instructions (test at home). Excellent resource. both hydrogenaudio, and you nice guys :D

THANKS!! :tpg:

Gawd, I'm about to pull my f***ing hair out right now.

Does anyone know of a good alternative to Audacity? I'm ripping files from a couple games, and most of them convert from WAV to MP3 just fine in Audacity. But there are these weird few that absolutely won't compute in Audacity, for no reason at all. I tried changing disk writers in Winamp, but with the exact same result. So the problem is with Audacity. Anyone know of any good substitutes? (I'm using Audacity to convert these WAV files to MP3 as well as to give them a 5-second fade-out at the end.)

I use Exact Audio Copy to convert WAVs ripped directly from CDs into mp3 but I use dBpowerAMP for anything else. The latter program requires a crack for you to use it as long as you want, though, so you might want to look for it on a torrent site.

Just to let you know, i did that conversion (lossless ape -> 128kbps WMA) following the options given at that hydrogenaudio page, and i am very pleased with the resulting files. I really have the impression that WMA's at low bitrates are superior in (subjective) sound impression than MP3's (FhG) at the same CBR-bitrate.

LAME V2 is as good of course, since it is VBR, and some files are as small as the low-bitrate-but-great-sounding WMA-CBR's. It all depends on the lossless source audio material --- i guess.

Which torrent site do you recommend? (I tried hunting around, but when I found a torrent site that required membership on a porno site, I pretty much figured I'm going to need some help on finding a more suitable alternative!)

EDIT: Ack!! Okay, I found a copy of dBpowerAMP that I could download--but it doesn't work right. When it asks for files to convert, and I go to the folder with my WAV files I want to convert...nothing comes up. It can't bring up WAV files! What gives? How do I make it bring up and convert WAV files?

Basically, I need a program that functions exactly like Audacity. =(

Not sure what the problem is there. You tried setting the 'Files of type' drop-down box to All Audio Files?

Chances are you might have a fake version of the program, though. I'll upload mine for you:

Download links - Sharebee.com, the one and only online file hosting distribution service.

Basil, Audacity is not solely a converter, but is mainly an audio waveform editor. Rew seems to need the ability to fade his recordings as well as encode them.

Rew, perhaps you can try the trial versions of Sound Forge or Cool Edit. Although, I can't remember, one of their trial limitations might be that you can't save your work...

Also, do you notice any difference about the files that Audacity won't open? Is it audio from entire games that won't open, or will only some tracks in the same game not work? Do they have unusual sample rates? And can you play the problematic WAVs fine in your audio player?

Thanks, everyone! Actually, I figured out a different sort of trick. The WAV files that would go nowhere in Audacity I opened in iTunes instead and converted them to MP3. Their sound quality remained intact, and this time, as MP3 files, I was able to play them in Audacity and do the five-second fadeouts that I wanted. So all that to say, problem solved!

Moguta: What was weird is that I couldn't find any commonality at all among the WAV files that Audacity wouldn't take. Tracks from literally the same folder of a game would convert splendidly, while a stubborn few just wouldn't at all, and no error messages were given either. Oh well. At least that's over with now. =0)

Modern audio encoder implementations do seem pretty competitive around 128Kbps, as demonstrated by the results of this public ~128Kbps double-blind listening test in December 2005:

http://www.listening-tests.info/mf-128-1/results.png

Although, this test isn't entirely relevant to your statement, since it used WMA Pro in VBR mode rather than CBR WMA. It's just too bad there have been no public double-blind listening tests performed with LAME's -V2 --vbr-new or --alt-preset standard modes. (In the above test, LAME is evaluted by its lower-quality -V5 --vbr-new setting.) I have heard that its simply too fatiguing for most people to try to reliably & repeatably discern between that level of quality and the original.

Additional Post:
That is strange, about Audacity not opening files randomly. Perhaps you could report it to the devs and see what they make of it, for the future.

And in case you didn't realize, when you open the MP3 in Audacity and then re-save it after doing the fade-out, you are actually re-encoding the MP3. (WAV -> lossy MP3 -> lossier MP3 w/fade)

To preserve audio quality, you could try:
1. Download Foobar2000 and do a full install... or at least make sure that you install the Converter component.
1b. Download & extract the current FLAC and LAME encoders (links in the 1st post of this thread)
2. Add the desired WAVs to Foobar's playlist, then select them all and choose Convert > Convert to... from the right-click menu.
3. Select FLAC, level 5 from the drop-down box, hit OK, and wait for it to complete. The first time you convert, it will also ask for the location of the FLAC encoder you just downloaded.
4. Import the FLAC files into Audacity, then delete the FLACs once you have encoded to MP3. Alternately, since Audacity only encodes in outdated CBR mode, you could have Audacity export the faded audio to WAV and use Foobar2000 to convert them into efficient, high quality VBR MP3s. Just add the WAVs and proceed like you converted to FLAC, but instead selecting MP3 (LAME), 190 kbps, V2, fast in Foobar's converter.

EDIT: Oooops, I forgot that Foobar's converter doesn't include the encoders themselves! Updated it to work.

Wow Moguta, that was interesting.. :) Thanks!

[...]

I'm still trying to encode (=rip from FLAC *images*) MP3's (LAME V2 v3.97) with foobar2000. I guess i must delete :( the downloaded FLAC-image if the accompanying CUE-image sheet is pretty much wrecked, am I right?

Well, I dont know much about correctly working CUE-sheets, but I do know that CUE-sheets (produced by ExactAudioCopy rips) sometimes need minor editing, e.g. the .WAV" WAVE needs to be edited to .APE" WAVE for APE-images, or CDImage.wav" WAVE needs to be edited to CDImage.flac" WAVE for FLAC-images.

But let's assume that the CUE-sheet is absolutely not working -- i dunno why -- (inside the CUE-file, the single tracks are labelled as APE's...for my huge FLAC-image); question/FLAC-images: Is there any good way to extract the single tracks WITHOUT ANY EXISTING/VALID/WORKING cue-sheet?

(If the image file were in *.NRG-image format, i would mount the image with Daemon-tools (virtual CD drive) and then rip the single tracks with foobar2000, Nero, etc.)

Thanks for hope or help!!

ADDIT: i'll be happy to post a sample §$%&! cue-sheet. i deleted most non-working downloaded flac/cue-pairs, but...

Why don't you post the cuesheet here and the file layout?

I hope you also know WHY you have to do this.

Post cuesheet and file layout. Otherwise nobody can help you.

NRG is an image format already with the cuesheet embedded. If you want you can also modify it, but it's harder because it's not in clear text like the "normal" .CUE-sheet.
Burning a disc without a cuesheet is not possible, some firmware also verifies the sheet (older burners did this and so had problems when cloning copy-protected discs).

What's our VERY FINAL *full* commandline for 'LAME CBR|VBR with foobar2000' ?
 

unexplained instructions for LAME VBR with EAC are given as:
http://img329.imageshack.us/img329/7...witheacff8.gif

explained instructions for LAME VBR with EAC are given as:
http://img153.imageshack.us/img153/5...heacgffbq5.gif

1. observation: the two 'LAME VBR with EAC'-commandlines differ in length: the 3rd hydrogenaudio-commandline is much longer. side question: Is it preferrable to the gff-commandline, for EAC-users?

2. EAC is not foobar2000, so the above screenshots could be "invalid" for me, since i am a foobar2000 user (EAC?? Too complicated for my little brains :( ) and am really missing a webpage which shows clear full commandlines to enter for 'LAME VBR|CBR with foobar2000'. The installed mp3 vbr preset looks like this, and here again, the commandline differs from the above two 'LAME VBR with EAC'-examples. :confused::
http://img206.imageshack.us/img206/6...hfoobargd0.gif

Well, what i need is simple; view me as a PC-newbie :D who wants to have 2 (and not 1) mp3-options with his foobar2000:

[1] conversion/ripping to "LAME newV2" with all automatic tagging included (written tags sourced from e.g. CD-TEXT, cue-sheets, mp3-tags, wma-tags, or even freedb.org, etc.) and no normalization. (i guess that "--noreplaygain" means "no normalization". but i dont understand the "-S" parameter..)

[2] conversion/ripping to "LAME CBR 192", again with all automatic tagging etc. included, i.e. the same as [1] except for CBR 192.

Question: what should i enter in the "Parameters:"-line of foobar2000 as the full commandline for [1] and [2]? --- the foobar2000-commandline, obviously, must look different from the EAC-commandlines since all three screenshots show different lines for the same case, namely for "LAME newV2". Confusing!! :confused:

i googled the inet for a webpage which exemplifies the usage of LAME encoder with foobar2000 in explicit different full "Parameters:"-commandlines, i.e. for case[1], case[2], and further popular cases, but didnt find any.. :gonk:

Thanks for some help!! :tpg:

In your first image, everything after --vbr-new and before %s %d is tagging parameters. Note that %a, %t, %g, and such are all EAC-specific parameters that EAC replaces with each track's values before it actually passes that command line to LAME.

To respond to each of your needs:

[1] There's no need to go into the Custom encoder mode in Foobar for this. Just choose MP3 (LAME), 190Kbps, V2, fast when encoding or converting. If it's not already in there, just select MP3 (LAME) for the encoder, drag the quality to the ~190Kbps, V2 tick, and make sure Fast Mode (--vbr-new) is checked. Foobar itself takes care of copying all the necessary tags.

[2] For this, you do need to go to Custom for the encoder. Delete -V2 --vbr-new from the existing LAME command line and replace it with -b 192 instead.

I have to mention, it is strongly recommended not to encode in CBR, unless doing so for an old device that literally does not support VBR. Even using average bitrate mode (ABR) is an improvement over CBR, and gives you the bitrate predictability that quality-oriented VBR lacks. (Encoding at an average bitrate of 190Kbps, for example, would be done --abr 190)

EDIT: Since you were curious, and I didn't know, I looked up the -S parameter in LAME's help. It simply suppresses the text-based encoding progress report (which is what you see when ripping with EAC), because Foobar has its own graphical progress meter. And --noreplaygain simply means it doesn't calculate the track ReplayGain after encoding every file, which is fine. You'd have to use another program to calculate the album ReplayGain anyway.

However it should be possible to calculate album RG when the track RG values are present, simply by weighting track RG with track length and summing up. I wonder why no application can do this, or am I missing something here?

Since ReplayGain relies on a geometric mean of small pieces of all the audio, I'm not sure that one can calculate album gain based on the track gain of all tracks in the album.

Right, I didn't think about that.

This is nuts- GFF should simply recommend people download the latest version of LAMEDrop, pick a quality setting, and go from there- dealing with all these custom switches seems (to me at least) more likely than not to result in people wrongly encoding, or encoding worse files than they could, simply because all the options will be meaningless to them.

Why not just use an easy drag and drop (not commandline) based encoder? And why not recommend that for newbs?

I run a game music website and understand compression reasonably well and would still NEVER recommend a command-line based encoder, no matter the person's technical undeerstanding.

- Spike

I disagree. If you don't know what a graphical interface does on the commandline you should either read the documentation or leave it be and let someone else encode the music (someone else with more experience).

Saves us from a lot of RTFM questions.

@"all these custom switches": I have only seen two usage of switches that don't relate to encoding quality: -S and --noreplaygain
Both are easy to understand (S = silent = turn down verbosity of the encoder; noreplaygain = don't calculate replaygain).
If you don't know RG you google it and read the Wiki entry. Plus that saves us from these annoying "Is RG = normilization" bullshit questions.

In addition try this with a GUI encoder: Have a bunch of FLAC files you want to transcode to MP3 (VBR V4) to use them on your portable (reason to only use V4) with only a minimum amount of user interaction (including the possibility of batch conversion). I can hack you a script using flac, metaflac, lame and eyeD3 (all cmdline tools) that does that fully automatically, even preserving file tags.
Include the script call into your context menu and you have a one-click solution to the problem. Nice, fast and accurate. You can even integrate upload to your portable IF connected.

Everyone thinking that using LAME (or any other application) on cmdline is difficult: You're wrong, you just need some time to read the docs. There are only a few options in LAME you need to memorize for basic LAME usage. That's five to ten minutes reading the docs and then you know how the cat jumps.

Saves you from a lot of trouble ("I know I have to use this and that switch and then I get a MP3....") and if you want to use a more exotic functionality you look it up (that's what the docs a there for).

Audio encoding is not about "it just works" (that's partially the reason why so many CBR320 rips are floating around, the people just don't know better), it's about "doing it right" and for that you need to understand what it means to "do it right".

LAME is the swiss army knife of MP3 encoding, but you still have to know when and where to use what part (knife, saw, wine opener... you get the picture).

Well, for one, using LAMEdrop means that tags must always be manually input. If you are transcoding, Foobar2000's converter will copy all of your tags automatically. If you are ripping a CD, EAC will automatically retrieve the CD info and appropriately tag the ripped MP3s. There's no need to make ripping a two-step process -- using one program to rip, another to encode, and manually entering tag information -- when it can all be done in a single stroke.

Also, talking about "newbs", LAMEdrop would likely be a strange program to them. It has no menu bar, it has no title bar or closing "x", it stays on top no matter what you do, every option is accessed by right-clicking on it, and it has no standard option to add files. The program gives no indication that one must right-click to adjust the options, and while it does say "Drop Files Here", it's only computer "newbs" who won't know how to drag & drop when every other program has a File > Open/Add Files menu selection.

LAMEdrop may not prevent newbs from messing with options they shouldn't, either. See "Encoding Engine Quality" at the bottom. While I can't be sure, because LAMEdrop doesn't let one see LAME's encoding process, that's probably adjusting the -q X parameter, which messes with the presets and should not be specified.

Additionally, I notice that since early LAME 3.98 betas, the "Fast" --vbr-new mode has become the default. However, in the LAMEdrop based on 3.98b6, the options still default to "Standard" rather than "Fast". I wonder if "Standard" passes --vbr-old or if it passed no parameter, just relying on it formerly being the default. If that's the case, then both modes are essentially "Fast". That's the drawback of easy-mode, no-command-line frontends; they break when commands change. And advanced users who actually know the commands can't tell exactly what the frontend is doing.

To be honest, I understand your concerns, Spike. I don't think there is any frontend or converter out there that is adequate for both "newbs" and experienced users. I just chose Foobar because I think it has the best and most advantages, with the fewest drawbacks.

Foobar2000 Pros:

1) Converts from compressed formats; does not require the user to convert to WAV first
2) Converts to multiple formats, all under the same program interface
3) Automatically copies all file tags
4) "Newb"-friendly sliding-scale converter options
5) Advanced users can see & modify the command line options
6) Files can be renamed, based on tags or other parameters, as they are converted

Foobar2000 Cons:

1) Is a media player, not just a converter
2) Encoders must be downloaded separately
3) "Newb"-friendly encoding options are somewhat limited*
4) Does not show detailed encoder progress during conversion

*Using LAME as an example, only VBR options are available.

LAMEdrop, on the other hand, shares ONLY the advantage of "newb"-friendly encoding options. Concerning Foobar's cons, though, LAMEdrop's GUI options are more extensive than Foobar's, it does not come with extra unneeded capabilities, and the encoder is right in the program. But, in my opinion, the additional power & capability of Foobar makes up for those cons, especially since LAMEdrop shares the lack of detailed encoding-progress information and has a non-standard interface.

My ideal converter would:

1) Just be a converter
2) Convert to and from multiple formats
3) Copy all tags
4) Have extensive GUI slider options for all standard modes
5) Have an advanced option to enable command line editing
6) Come with currently recommended versions of all encoders, allowing replacement
7) Optionally show each encoder's detailed DOS-shell progress when encoding
8) Allow files to be re-named & re-pathed on conversion

However, as far as I know, no program like this exists yet.

Good post- I didn't know foobar could use LAME to encode. Got a screenie of it?

I agree with you wholeheartedly. I figured LameDrop was a very simple put together program which just ran default scripts and all you could do pretty much was change the quality- which is all you want "newbs" to be able to do.

I'm also confused about the Standard v Fast thing, I might post on HA about it.


I also agree with LA's comments about command-line encoders (abbreviated to CLE for ease)- I still use CLE's for many things, mainly DVD-Audio decoding (I do a lot of this) and weird format decoding (e.g. MPC).

But we're not talking about us who are PC savvy, we're talking about Joe Audio who doesn't understand what a CLE is, let alone what -v means and isn't likely to post a question here to ask, well, anything.

And I find CLE's confusing and I understand DOS pretty well, and am better-than-OK with PC's. I doubt most newbs would bother, either asking for help, or bothering with CLE's full-stop.

- Spike

I remember playing a lot of these SCUMM interpreter games from LucasArts when I was younger (Larry, Space Quest, etc.). All of these older games were "commandline" interpreter based (except the mouse which could be used to walk around). You typed in the things you wanted the character to do.
My english was terrible back then and I was always sitting with a dictionary in front of my father's desktop computer (Intel 286). But I managed to master these games, despite all the difficulties.

Now these were games, and today I have a bit more experience with the english language. Using the commandline (oh yes, the commandline is NOT DOS - that's just plain wrong) is the same as telling Roger Wilco to stuff a ladder into his pocket (I'm still wondering how he did that...) - only much more advanced.

I don't see the problem with commandline, I'm seeing a problem with a mega colorful dumbed down interface with just one big button "DO IT" and no way to tell the app how to do it (in fact you would not see the other buttons even if there were any because of the overflowing usage of visual effects).

And I wasn't quite PC savvy back then, my primary problem was the language.

I'm not saying that everyone should go back to the commandline and abandon all graphical interfaces, but it's just wrong to think (or tell people) that using cmdline is deprecated. And it's not only for the computer expert but for everyone who can read and understand the english language (or you're lucky and ther app was multi-lang support). Everyone can open a commandline on his system and roam around his system using "cd" and "dir", that's no rocket science. And if you're lost you can always type "help" (at least on the windows cmdline).

The problem here is that most people don't even understand the concept of a directory or a file, even if the concept is based on our reality (and is quite simple). We're not going to solve this with even more eye candy...

As already said. There are a few basic concepts you need to know, everything else you have to look up (docs, google, etc.). So one of the basic concepts is how to look up information, including the use of a search engine.

I'm fine with DOS commands- obviously, I played plenty of Sierra games and had to learn DOS.

What I don't understand is particular command-line program code, individual to each program (as opposed to cd and dir and so forth). There's plenty of command-line DVD-Audio rippers whose command-line programs are near-impossible to use because of all the commands and switches you have to configure.


And I don't think I said using command-line programs is going to result in worse quality because of the program- it's because of users being bombarded with terms they don't know, that the worse quality results. I personally find MP3 switch terminology confusing and I have a good understanding of encoding and am an audio enthusiast. I just don't feel the need to know it, when I can use a GUI which does the same thing.

I'm pretty good with Google, too.

BTW, I didn't even realise English was your second language- you speak near-perfectly. :)

- Spike

Great :-)
Another user who spend countless hours on editing config.sys and autoexec.bat to squeeze out another 2KB to run a particular game! *g*

That's probably a problem originating from the Windows world. On the *nix side you have rather standardized commandline tools. Means the syntax and calling conventions are very similar. And most of the time the app supports a call with "--help" or "--longhelp" to get a brief intro (or the long one) on the usage. Manual pages are almost always included with a software package explaining what which option and flag does.
However one should not forget the topic "sane defaults", that's what you mention above. The author of the application should set some standard options which work for the majority of the people, sometimes that's possible but sometimes not.
The best thing with these apps is to create a wrapper script supplying "your" sane defaults to the app (plus the parameters from outside of the script). I have 7zip installed on my gentoo box and 7zip doesn't have GUI yet, so I always use the commandline to compress/decompress. Because the standard parameters don't fit my needs I have written two small scripts, one for normal compression and one for password encryted compression. Like the FLAC-MP3-transcoding script this one is integrated into my context menu.
Even better is getting in contact with the author of the app and discuss changes with him. Especially open-source projects are very interested what the user thinks about their work. And they are even more approachable when they notice that you've put a lot of effort into your ideas. The ne plus ultra situation is someone supplying sourcecode patches implementing his ideas to the project (I'm currently doing this for the pcsx-df PSX emulator project, but it's only a source cleanup in a plugin).

Ultimately it boils down to CBR / VBR encoding mode and which quality I want. I would already appreciate it if people would stop using CBR mode if they are intending to playback the audio on a recent system or portable and instead use the superior VBR modes.
There are still a lot of other options, concerning input audio format, ID3 tags, replaygain, joint stereo options, filter options, psychoacoustic model tuning, etc. - but LAME does pretty good with sane defaults and when doing your regular encodings from WAVE files with header you don't have to change anything there.

See, and it helps a lot, doesn't it? :-)

Thanks, I always though it was terrible. :-)

Cheers,
liquidAcid

Hey man,

In case you didn't know, I run a Sierra game music website- Sierra Music Central

Yeah, I spent way too much time editing those guys, not just for memory, but for Sound Blaster settings- damn SETBLASTER variable.

MP3 has no sane defaults. People still think CBR is the way to go, or that any VBR settings are fine as long as it's VBR. You shouldn't need to be choosing complex options, you should have only CBR or VBR, and if one, then which quality. That's why I like these drag and drop encoders, that's all you can do.

It's definitely possible with MP3. LameDrop isn't perfect but it's a lot better than recommending command-line to everyone, IMHO.

Do you mean a batch file (or equiv. in Linux), or programming something?

that's fine, but I'm of the opinion that a program should be able to be used. If there's no manual or a poorly written one, then that's the maker's/dev's fault(s) and will put people off.

But we're digressing- we're not talking about users like us, we're talking about the mass public, who don't know what CBR or VBR is- do you think they're asking LAME dev's what -v means, or much else? They don't even post here much about that stuff.

Well, exactly- that's why these GUI's have VBR at the top and CBR is always listed second.

LAMEDrop supports tagging and decoding, so it's a pretty sweet deal. I don't think many people are concerned with tuning or filtering (if you are, go become a LAME dev, you sound more than qualified!).

The point being, we're talking about acceptable gamerips. Really, 192 CBR would be acceptable to most, but when we're talking about recommending an encoder, we should be ditching the command-line confusion and saying "Hey, there's this great little program called LameDropXPd. Easy to configure to get great quality MP3 files. Blah blah blah.." and so forth.


And your English is extremely good. Most Europeans speak better English than most native speakers, to be honest! (Assuming you're European, but it seems the most likely.)

- Spike

Will take a look, didn't know about that.

I started very late with soundcards so I used the PC speaker for most of my DOS games. Made it very easy to setup the game but the sound quality... we shouldn't talk about that :-)

Sure, concerning quality there can't be sane defaults because everyone has to decide for themself how much quality they want. But I was more referring to your DVD-audio rippers.

That's also what the commandline encoder does. If you simply call it with
it produces a good quality MP3 file. No need to set any more options. But if you want you can modify a lot more options. That's what most drag and drop encoder frontends lack. If I wanna do something more sophisticated they all fail.
Of course you can argue if choosing a GUI over cmdline is a matter of taste (in the simple setup, where you don't wanna change any more options except the encoding quality). You may already have noticed, I'm quite retro when it comes to this :D

The problem is that most people hate the keyboard. They want to reach to every far end of the system with a simple click. If people were more accustomed to using the keyboard I suspect using cmdline would not be such a big problem for them. That's probably again a matter of taste. I also use both keyboard and mouse, but personally I find it far more intuitive to use commandline.

Just a simple batch/bash script. No need to fire up your development environment.

I totally agree. The thing is that I'm using a lot of free software here (free is open-source for me). There is quite a bunch of tools and applications that are really good, even surpassing anything commercial I have seen in the windows world. But I'm not paying anything to the developers, who put their own free time into their projects.
To give these projects something back I give the authors feedback about bugs or feature requests in their code. That's the least I can do. And it pays off. If someone uses 5 minutes of his time to write a decent bugreport for the problem it's sometimes fixed within a couple of days. Try that with a commercial program. Likely you're totally ignored by the support and when the new version comes out you have already switched to another app (or the new version costs additional money). Or the bugs wasn't fixed at all.
Plus you have the community. That's very different when working on Windows. I rarely see people posting bugreports for closed-source software. The whole mindset differs. Like you said e.g. the people expect the software to work, if not they blame the programmer/author.
I can't blame the programmers and I can't demand anything.

One example: My friend was having boot problems after he updated his linux kernel the last time. Downgrading was no options because he needed the new functionality. The problem was a lengthy delay when scanning for harddrives. Didn't happen with prior versions, so something was wrong. Now his laptop is rather old, something around 5 years, or even more. There is definitely no support for it.
I encouraged him to post his problem in the kernel bugtracker. He did and a developer did take a look at the problem, wrote some additional debug code which my friend tested on his system. I took only 2 days to solve the problem. The patch to the problem is now included in the stable gentoo kernel sources.
Try this on windows, you won't get far when encountering such kind of problems. People are forced to update hardware because support runs out, even if it's only five lines of code to change (code they don't have access to).
See... different mindset :-)

I expect people to read the manual which comes with their hardware. I do the same for software. If you blame the programmer that you can't use a particular piece of software and you haven't even read the docs... you're just stupid. Software is sophisticated... nobody does expect to drive a car if he hasn't used one in his whole life... so why does anyone make such assumptions for software?

I think the LAME project is doing very fine without me :-)
However I was thinking to apply to the Google Summer of Code in the next year. Maybe helping the wine project or so... (so I can finally play Blood 2: The Chosen on linux :cool:)

I agree, but I would replace the "Blah blah blah.." with "And if you need more options take a look at LAME itself". Give people the opportunity to use a software to their full extent.

European is right, german to be exact. However I had a terrible english teacher. I made some improvement through english movies and literature though. My sister is far better when it comes to languages. Something that will always stay beyond my grasp (but that's fine with me *g*).

Greets from Germany,
liquid

Thanks very much! I was looking for a way to get better quality from CDs I have!

Hello eveyone,

i've got a problem with foobar2000.
does anyone know why the bitrate is not constant if you convert several
ape/flac-tracks to mp3?
i chose MP3-LAME V4, 165kBit/s. but sometimes the botrate is 192, sometimes 160, sometimes 224.
it always varies. what do i have to do to make it constant?

thanks in advance, janice1423

The question is: Why do you want a constant bitrate?

VBR stands for variable bit rate, so you can expect different average bitrates when encoding multiple files.

i just like constant bitrate!
"VBR stands for variable bit rate". i was not aware of that, sorry.

is it impossible to make the bitrate constant (with foobar2000)?

Constant bitrate is pointless. VBR v0 is really second only to lossless for sound quality. It uses the bitrate when its needed and lowers it when it isn't. it's the best quality in the least space. If you're not running in .flac or apple lossless, you should be running v0.

thanks for all your responses :)

my question was: is it impossible to make the bitrate constant (with foobar2000)?
a simple "yes" would do. if the answer is "no" (if it IS possible) please explain me how to do it constant.

thx in advance

I've never used foobar but can't you just choose a constant bitrate instead of a variable one?

Sure, you can use LAME in CBR (constant bitrate) mode and just select the bitrate.

I think what fb2k does is to let the user select sort of a "target bitrate". Of course such a thing doesn't really exist and is probably based on a bunch of selected encodes.

@Janice: So yes, it's possible. Read the LAME docs how to do it. Maybe fb2k doesn't expose the functionality, but LAME is completly capable of generating CBR encodes.
Keep in mind though that CBR rate is obsolete. If you wanna max out quality/filesize ratio then use VBR modes.

thank you :)

Hi Janice, yes it is possible with foobar2000 to make the bitrate constant. I've tried to figure it out how (by reading .. etc. .. ) but i dont know how (step-by-step procedure). Indeed, foobar2000 has no exposure for LAME constant bitrate settings (and the manipulation of its settings/options/configuration is pretty hairy). Foobar's GUI is optimized for LAME VBR, no doubt on that. (otherwise we would have found out WITHOUT READING ANY MANUALS *RTFM* how to set it to CBR).

And i use LAME V0.

thanks for the information, lousy. sorry i didn't say "thank you" earlier. but i'm really rarely in this "Guide to Ripping & Encoding High Quality MP3s " thread.

i appreciate your help ;)

Hey Moguta, it seems like LAME 3.98 (3.98.2?) is the current stable release. I haven't noticed anyone using it yet, but I guess it is safe to go with it, right?

Indeed. I've certainly been using it recently. 3.98 has some minor quality and speed enhancements. And you can now specify very granular VBR quality settings, like -V 2.24 for example, rather than being constrained to whole integers.

Guess that means I have to update the guide for the new version, huh? :p

Additional :( Spam:
Cleaned up a few other things too. :)

• Updated 'Encoding from Files' section to reflect changes in Foobar2000 v0.9.6
• Removed all mention of the rare, long-stagnated Musepack codec
• Updated LAME to version 3.98.2 and Ogg Vorbis to aoTuV 5.61
• Changed recommended Error Recovery read-attempts to Medium

So I decided I'm going to stop using LAME 3.97 and instead use either LAME 3.98 or LAME 3.98.2. I don't upgrade mp3 encoders often (I prefer lossless over mp3) and to me it seems like 3.98.2 has just a very minor fix.

Would it be just as reasonable to use 3.98 instead of 3.98.2, at least until the next version of LAME (ie 3.99) gets released?

Might as well use 3.98.2 since it doesn't really make sense not to get those bugfixes.

God knows why you'd need cbr mp3, but all you do is select LAME, go to custom, and replace "-V 2 --vbr-new" with "-b 192" or w.e it is you want.

Well, the fact that #gamemp3s seems to have upgraded to 3.98.2 seals the deal for me, I will start using that then. Thanks.

(I hope you realize you're responding to a post nearly 5 months old. o.o)

Guys, what's the difference between the modes "new VBR" and "old VBR" on Lame encoder?
I am kinda new in ripping my CDs using VBR. Previously I ripped'em using CBR.
I use the following settings in Easy CD-DA Audio Extractor
http://img8.imageshack.us/img8/8054/settings1u.jpg


Should I be using Min bitrate limit when I am ripping with VBR V0?

You should disable min and max bitrate, since the VBR algorithm should figure out this itself. It's generally only needed if your playback device can handle VBR. but not fully (some very old portables can handle VBR if the bitrate per frame doesn't exceed like 192kbit/s - a friend of mine still owns such a device, so he needs this options).

Concerning the VBR mode. You probably should read the LAME docs (and the mailing list) about this topic. Some time ago the LAME project became dissatisfied with their VBR implementation, so they did an entire rewrite of the thing.
However they left the old VBR implementation inside the code, so the user could switch back and forth between them. This was necessary in the beginning since the new implementation was doing some things better but a lot things he did worse than the old impl. However this is long ago and the new VBR mode is now considered more efficient and smarter than the old one. Since the new LAME release the new VBR mode is the default one. So you probably never want to go back to the old mode.

I wouldn't the surprised if some time in the future the old code is completly removed.

As LiquidAcid explained, there's no reason to use the old VBR mode. The new mode is much faster & generally higher quality.

I know the Min & Max Bitrate settings are probably a bit confusing for newbies. They do NOT refer to the averaged bitrate of the overall file. To explain what it means, I have to get a bit technical, so I hope I don't lose you here:

MP3s consist of a series of audio "frames", each frame representing about 26 milliseconds of audio. Variable bitrate (VBR) works by giving these frames different sizes based on how complex the audio-data is in that section. In a constant bitrate (CBR) MP3, however, these frames are all the same size. For example, every frame in a 128Kbps CBR MP3 is about 417 bytes.

Somewhat confusingly, those minimum & maximum bitrate settings mention Kilobytes per second when they're actually limiting these 26ms frames. For example, setting a minimum bitrate of 128Kbps means the VBR encoder will use a minimum frame size of 417 bytes (the frame size used in 128Kbps CBR MP3s). Restricting the frame size like this is a problem, because an unrestricted VBR MP3 can use any frame size from 104 bytes (32Kbps equivalent) to 1,044 bytes (320Kbps equivalent). For VBR to work best, it needs access to this entire range.

Even if you need smaller files, a maximum bitrate setting is NOT the way to go. One, you'll be limiting the encoder's ability on the most complex audio passages, making audio flaws much more likely. Two, a graph of frame sizes is usually spike-shaped... meaning the larger and smaller frames are used far less often than the mid-size frames. So limiting the maximum bitrate won't even affect that many frames, and thus won't save much filespace anyway.

Setting a minimum bitrate is just wasteful, as there are many songs which won't need high bitrates to sound just like the original. I have some -V2 encoded files that are slightly less than 120Kbps, and others that are over 200Kbps. It's just VBR working as intended: encoding based on the audio complexity, with the goal of consistent quality, rather than encoding to a certain filesize.

The lesson here is to never use the minimum & maximum bitrate settings under any normal circumstances. If you want different filesizes, either change the VBR preset number, or use average bitrate (ABR) mode for more targeted sizes.

Thanks Moguta & LiquidAcid!;)






I understood.
First of all if you saw, I am using 320Kbps for the Max bitrate, which is the highest bitrate for the MP3 format. Ergo I am not "limiting" the VBR algorithm, because I chose the Max Bitrate to be 320Kbps.

The truth is that VBR is marvelous (in compare to CBR 320Kbps), because I save space for the whole album, which "additional" space was killing me in the upload (as I happen to have relatively slow upload speed).


On the other hand by using a min bitrate, I just waste some space, right?
For istance there's a frame tha needs 140 Kbps, but I've set the min bitrate on 224Kbps. Hence the VBR algorithm is going to choose 224Kbps for that particular frame, and subsequently waste some bits (224-140 = 84), right? My rational guess is that this won't affect the transparency of the mp3, right?

You're right, a 320Kbps maximum bitrate is the same as not having a max bitrate at all. Sorry if it came across like I was attacking you. This was not my intent, rather I was just trying to give a full explanation.

And yes, you'd just be wasting space with the minimum bitrate. But why specify a minimum? It's essentially saying that you don't trust the VBR mode to pick the right bitrate, but you're using VBR anyway. I would just disable the min/max and let the algorithm do its thing. In my personal opinion, -V0 is quite overkill enough. I typically use -V2, and there are many songs I can't hear a difference on (even through my hi-fi headphones) when I go as low as -V3 or -V4!

Ugh, all this time I've been using 192kbps as a minimum bitrate in EAC, but no maximum bitrate. Time to go change some settings again.

It's all Kairyu's fault :mad:

Luckily I only fetch your FLAC encodes Grovyle :)

I know this thread hasn't been updated in forever, but I'm running into MAJOR issues with Lame and Windows 7, mainly that it refuses to encode the mp3s, even when I'm using RazorLAME.

Additional Spam:
OK, I figured it out:

On the newer versions of EAC, don't be dumb like me and choose LAME as the compressor. Choose User Defined. Like the faq says.

Hey Moguta, I'm trying to set up the most recent Exact Audio Copy V1.0 beta 3 (and LAME 3.99.5), but I'm having trouble getting this code through:


I copied and pasted it under "Additional command line options" like your guide says, but when I hit "OK" it gives me an error message: "Invalid replacement tag found."

(The default code is %islow%-V 5%islow%%ishigh%-V 2%ishigh% --vbr-new %source% %dest%

should I just use that?)

Any ideas? Thanks.



Edit: I think I figured out what the problem was. It's the new parameter markers. Instead of %s for source and %d for destination, they're now %source% and %dest%. So I ended up typing in: -V 0 --vbr-new %source% %dest% which is accepted.

Evidently this guide needs a bit of updating, since EAC now uses the recommended encoding method for LAME (-V 2) when the "high quality" option is checked (%ishigh%-V 2%ishigh%). Plus, nowadays I tend to rip with Burst Mode and Test & Copy then look at the CRC column for "OK" results, since this is so much quicker than Secure Mode.

Still, glad to see it's a useful resource after all these years. ^.^