[Pat]

So what's the best encoder? Last time I listened to mp3s was over a year ago. Back then I used CDex because it was a great little prog in its early stages that was fast, simple and effective. Personally I hate all that extranneous crap. What I want is a plain, simple, encoder. Skins, fancy players with neato reverb effects - big turnoff for me. Any recommendations?

I *know* this was on headwize. I'd rather search then ask again. Too bad I can't.

 

[chych]

LAME encoder... can't get simpler than that...

http://www.mp3dev.org/mp3/

 

[neil]

Okay, I know you didn't want the frilly stuff -- but I have to mention this one because I like it:

I really like Media Jukebox at http://www.musicex.com/mediajukebox/index.html. It's a player, organizer, and importantly, an encoder. It allows you to easily plug-in different encoder schemes.. it supports Lame MP3, Ogg, VBR, the works. Plugging in new encoders is a couple clicks.. really easy stuff.

I did pay a little bit to register it, but heck, it's a great program and I definitely suggest that you at least give it a trial. (free trial) I know there are free encoders out there, but phew, this one is really fantastic in terms of how easy and flexible the configruation is.

You choose your bit rate (quality), and even perform easy batch conversions.. it also uses the CDDB so that your MP3s are properly named / sorted (if you so wish) to the artist and song title.

 

[Pat]

After doing a little "research" - turns out LAME isn't as much a joke as I thought it was. Its actually one of the best encoders out there, if not THE best. The new CDex version carried the LAME encoder, so I figured I'd give it a whirl.

I used to think that when the bitrate frequently jumped up and down it during playback it was a sign of a corrupted mp3 or something nasty of that sort. Apparently this is VBR (variable bit rate) MP3 at work. I'm not sure exactly how it's done or how it improves the sound, but the quality is absolutely AMAZING, for an mp3 at least. I'd have to say it's quite a bit better than mp3s encoded at 256 - a standard I used to encode at. I suggest some of you try it out if this isn't already old news to you.

Hey, it's new to me

Feedback on your LAME experience or settings using CDex would be nice. Right now I'm going with:

Thread Priority: Highest
Version: Mpeg I
Min Bitrate: 128 kbps
Max Bitrate: 320 kbps
Mode: Stereo
Quality: High >160 Kbits/s
VBR Quality: VBR0

If anyone can offer any suggestions for improvement, I'd greatly appreciate it.

 

[Neruda]

from what I've heard, variable bitrate is not as good as a constant bitrate. I'm not the best source of info though. Personally I use Exact Audio Copy with LAME. It works very well for me and I love having all my CD's on my computer, it makes it incredibly easy to bring up any album I want at any time.

 

[jonpile]

Thought I'd throw my favourite encoder front-end into the mix... "Digital Audio Extraction" from http://www.windac.de/

I liked it enough to pay for registration. It's no-frills, but feature-complete. CDDB lookup, plugin architecture for new encoders, excellent filename control stuff.

Personally, I use CBR at 192kb/s (some people are more comfortable at 256kb/s). I find that it's a decent tradeoff between filesize and sound quality.

-jP

 

[tziko]

From personal experience and from the many people at the SA NMP3s forum, I think LAME VBR is the way to go. To get more information on it, go to http://www.r3mix.net .

Btw, when encoding with LAME, using the --r3mix option is a very good way to record IMHO. It creates a very good quality MP3 with a decent filesize.

 

[Merg]

Quote:

Btw, when encoding with LAME, using the --r3mix option is a very good way to record IMHO. It creates a very good quality MP3 with a decent filesize.

I completely agree. I ripped my entire CD collection (3800+ files/20+GB) with lame --r3mix -b128 (the -b128 is an 'older' extra setting, just to be sure) and I'm extremely happy with it. The avg. bitrate is 180kbps. The advantage of VBR is that it takes more bits as needed. There are songs which are have an avg bitrate of 240-250+ and other songs have an avg bitrate of 130-140. It scales very nicely while maintaining superb quality.

 

[Pat]

Well I went with EAC and LAME. Fantastic stuff. Takes longer to get from CD to mp3 but it's no biggie. VBR is awesome. Small file size, better sound quality than CBR in my opinion. The --r3mix option makes things a lot easier too.

Now if only they'd put out some stable versions of both EAC and LAME....

 

[Nawhead]

I still use Fraunhofer's MP3ENC 3.1 command-line encoder for archive purposes. LAME is fast and sounds good and all, but stuff encoded with it has always seemed too bright and agitating to me. It also produces more clipping than MP3ENC, as well as still producing more sound artifacts (remember, MP3Enc 3.1 is reference to the LAME developers). Current CD's which have been compressed to hell sound even worse when encoded with LAME. It's not so bad with MP3ENC though. It sounds very nice with MP3Enc actually, or as nice as it can sound after being compressed.

Too bad you have to pay to use MP3ENC 3.1. Errr....

 

[MacDEF]

Quote:

Apparently this is VBR (variable bit rate) MP3 at work. I'm not sure exactly how it's done or how it improves the sound,

The theory behind "variable bit rate" is that some portions of a song just aren't complex enough to warrant using a high bitrate, so the encoder examines the content it is about to encode, and estimates the lowest bitrate necessary to maintain a "high" (subjective term, of course) degree of sound quality. This means that different parts of the song are actually encoded at various bitrates.

In theory (and in practice, IMHO), a 320k MP3 will sound better than a variable-bitrate MP3 with a range of 128-320k. However, the latter will be much smaller, which is the primary attraction of variable-bitrate encoding.

 

[ff123]

Quote:

I still use Fraunhofer's MP3ENC 3.1 command-line encoder for archive purposes. LAME is fast and sounds good and all, but stuff encoded with it has always seemed too bright and agitating to me.

Lame does pretty good with the --nspsytune setting. For files that average around 192 kbit/s, try:

lame3.89 --abr 192 -h -mj --nspsytune --athtype 2 --lowpass 19

For pretty good sounding constant-bitrate 128 kbit/s files, try:

lame3.89 -h --nspsytune --athtype 2 --lowpass 16 --ns-bass -8

Quote:

It also produces more clipping than MP3ENC, as well as still producing more sound artifacts (remember, MP3Enc 3.1 is reference to the LAME developers). Current CD's which have been compressed to hell sound even worse when encoded with LAME. It's not so bad with MP3ENC though. It sounds very nice with MP3Enc actually, or as nice as it can sound after being compressed.

Added clipping only occurs during the decoding process, even though encoding files which are compressed to hell highlights the problem. The best solution, IMO, is to use mp3Trim to reduce the gain after encoding by 1.5 dB. It's fast, reversible, works without having to decode to WAV first (then re-encode) and it eliminates just about all added clipping.

ff123
Discussion of Audio Compression
http://fastforward.iwarp.com/

 

[crk]

ff
I've used Lame quite a lot but I've never found a description of what the --nspsytune or the --nssafejoint switches do and how they compare to the other hearing models in Lame Can you enlighten me

TIA
crk

 

[ff123]

nspsytune is Naoki Shibata's psy model, which basically replaces the default gpsycho when used. Here is Naoki's own description of it:

Quote:

The differences between default psymodel and ns psymodel are following : 1. Method to calculate tonality. It's not based on unpredictability. nspsytune calculate tonality from (maximum intensity of the spectral lines in a sfb) / average. 2. Method to calculate ATH. 3. Use -X0 and 'careful noise shaping' when encoding in CBR mode. 4. Method to switch between long and short block. It's not based on perceptual entropy. brief explanation of the new method is following: i) high pass filter the input sample at fs/4. ii) calculate energy of every 64 samples(the 1/3 length of a short block). iii) if there is large rise of energy from previous 64 samples, the switching routine thinks there is a surge, and switches to short block. iv) the routine allocates more bits to the short block where surge exists. 5. Allocates more bits to short block in which attack exists. see above. 6. Method to calculate masking in midside stereo. First, calculate masking of M and S channels in usual manner. Second, if ((masking of M)+(masking of S))/2 exceeds (3.5*masking of L) or (3.5*masking of R), reduce masking of M and S so that they don't exceeds those values. 7. Method to switch between midside stereo and regular stereo frames. Calculate estimated amount of bits used in a frame assumed that the frame is coded in LR, and calculate similar value of MS. If estimated amount of bits used in LR mode exceeds MS, the switching routine switches to MS mode. 8. Better reservoir handling. Not based on perceptual entropy at all. It's based on estimation of bit use described above. Improved samples: vbrtest.wav It was a problem of tonality handling. Improved by 1. applaud.wav Improved by 1 and 3. hihat.wav castanets.wav Improved by 4 and 5. gspi35_2.wav Preecho was heard because block type switching was not done properly. Improved by 4. youcantdothat.wav Improved by 6 and 7. Degraded samples: fatboy.wav spahm.wav

The main effect of using nspsytune is to eliminate "dropouts" which cause audible artifacts below 16 kHz. People complain about Lame "ringing," especially at bitrates like 128 kbit/s, where it sounds worse than the FhG decoders to people with good high frequency hearing (similar to the way Blade sounds). nspsytune mostly fixes this.

nssafejoint works in conjunction with nspsytune, and is a more conservative way of doing joint stereo. It helps, especially with VBR, but increases bitrate on average over regular -mj. With very low bitrates (eg., 56 kbit/s) you're better off not using it. Somewhere between 56 kbit/s and 192 kbit/s, the tradeoff between allocating bits for fixing dropouts and allocating bits for fixing joint-stereo problems shifts in favor of using nssafejoint.

downsides of nspsytune: it has a tendency to blur sounds and add low frequency noise at lower bitrates, but this can be tuned using --ns-bass (Naoki also has --ns-alto and --ns-treble tuning parameters). Also nspsytune is not optimized at all for speed.

ff123

 

[crk]

Wow! Thanks, I'll give --nspsytune a try.
I notice you use ABR as opposed to VBR. I'd be interested in your views on their relative merits.
TIA again
crk