Guide to Ripping & Encoding High Quality MP3s

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

Jam it back in, in the dark.

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

There's nowhere I can't reach.

Originally Posted by Lousy

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?

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

Originally Posted by Lousy

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.

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

Originally Posted by Lousy

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?

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

Originally Posted by Lousy

(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!!

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).

This thing is sticky, and I don't like it. I don't appreciate it.

Originally Posted by Moguta

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?

I am a dolphin, do you want me on your body?

Right, I didn't think about that.

I was speaking idiomatically.

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).

What kind of toxic man-thing is happening now?

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.

FELIPE NO

Originally Posted by Spikey

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

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*

Originally Posted by Spikey

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.

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).

Originally Posted by Spikey

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.

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.

Originally Posted by Spikey

I'm pretty good with Google, too.

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

Originally Posted by Spikey

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

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

Cheers,
liquidAcid

What, you don't want my bikini-clad body?

Originally Posted by Spikey

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

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

Originally Posted by Spikey

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

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 :-)

Originally Posted by Spikey

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.

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.

Originally Posted by Spikey

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.

That's also what the commandline encoder does. If you simply call it with

lame -V2 yourfile.wav

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

Originally Posted by Spikey

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

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.

Originally Posted by Spikey

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

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

Originally Posted by Spikey

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.

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 :-)

Originally Posted by Spikey

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.

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?

Originally Posted by Spikey

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!).

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 )

Originally Posted by Spikey

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.

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.

Originally Posted by Spikey

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.)

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

Jam it back in, in the dark.

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.

There's nowhere I can't reach.

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.

This thing is sticky, and I don't like it. I don't appreciate it.

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.

I am a dolphin, do you want me on your body?

Luckily I only fetch your FLAC encodes Grovyle

I was speaking idiomatically.