Guide to Ripping & Encoding High Quality MP3s

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

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

Hey man,

Quote:

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*

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.

Quote:

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.

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.

Quote:

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.

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

Quote:

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

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.

Quote:

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.

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

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