Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: LAME for VBR, Franhofer for CBR? (Read 13039 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME for VBR, Franhofer for CBR?

I've read an article here > http://www.noodle.mx/the-audacity-to-podca...acity_tutorials saying that:
Quote
LAME is the best VBR encoder. It was designed to encode music at a variable bitrate and it performs this better than any other popular encoder at the same quality (even Ogg Vorbis in most cases). Fraunhofer is the best CBR encoder. It was designed to encode audio at a constant bitrate and it performs this with better-sounding quality than LAME.
  What are your opinions on this?
sin(α) = v sound/v object = Mach No.

LAME for VBR, Franhofer for CBR?

Reply #1 –
My guess is that if you can hear any difference, it will only be a very low bit rates.

LAME for VBR, Franhofer for CBR?

Reply #2 –
Generalizations are always false  But seriously, it depends on the coded material and to some extent on the bit rate. VBR, i.e. "constant quality", is not as easy as it sounds. You may run into the problem of undercoding. I've seen CBR/ABR encoders doing better than VBR encoders on some items.

Note also that what Fraunhofer calls CBR is actually ABR (average bit rate = VBR constrained by the size of the bit reservoir), which is a much more efficient approach than true CBR, and that Fraunhofer also features a decent VBR mode.

See also http://www.hydrogenaudio.org/forums/index....showtopic=67529. Where are the results archived again?

Edit: Got it: http://listening-tests.hydrogenaudio.org/s...8-1/results.htm

Chris
If I don't reply to your reply, it means I agree with you.

LAME for VBR, Franhofer for CBR?

Reply #3 –
I wouldn't be so sure about Lame being generally better than Vorbis at the same bitrate...

LAME for VBR, Franhofer for CBR?

Reply #4 –
I personally use FhG ACM for CBR encoding (especially on 128kbits/s). It has been a subject of debate on the quality of FhG vs. LAME on CBR. LAME devs have focused on VBR tuning on later versions (3.97 and later), and there has been quite a consensus on LAME regression on CBR on the said versions. http://www.hydrogenaudio.org/forums/index....amp;mode=linear

If I have to use LAME for CBR, I use version 3.90 or 3.93. For newer versions, I set the lowpass at 16kHz.

Please do your own tests. On my personal tests, I prefer FhG ACM for 128 CBR over LAME 3.97 128 CBR (and at other bitrates as well).

In summary, I subscribe to the title of your post. Yes, I use LAME for VBR, FhG for CBR.
"Listen to me...
Never take unsolicited advice..."

LAME for VBR, Franhofer for CBR?

Reply #6 –
Quote from: Rio on
... and there has been quite a consensus on LAME regression on CBR on the said versions. http://www.hydrogenaudio.org/forums/index....amp;mode=linear

Thank's for this. Probably I read it when it arrived, but I wasn't aware of it anymore.
As CBR320 is still the recommendation for best quality your link is of vital importance.
The consequence is (up to the day when CBR is implemented again with the same care as has been done with VBR and AFAIK robert is about to do this) that it's best to use the VBR audio coding mechanism also for CBR 320 encodings. robert has shown the way there in the thread above.
With CBR320 there is the advantage that an artificial upper limit for the bitrate isn't necessary as 320 kbps is the highest bitrate anyway. The disadvantage is that standard -V0 produces a bitrate which usually is far below 320 kbps and you don't get the quality you'd expect from 320 kbps (of course you just get the quality of -V0). This is where my usage of -V0 drops in. I use negative values for --ns-bass/--ns-alto/--ns-treble in order to increase the SNR, that is to make -V0 more defensive. With my personal settings I arrive at an average bitrate of 277 kbps but the setting can easily be extended to arrive close to 320 kbps.
Current Lame is a little bit faulty with respect to --ns-treble and --ns-sfb21. That's why I use a variant of Lame 3.98.4 which corrects these faults and optimizes --ns-bass/alto/treble a bit for my purposes.

Those who want to try this special CBR320 approach can use my version.
For those interested in the changes they are here.

For CBR320 I suggest to use a setting like -V0 -b 320 -F --ns-bass -12 --ns-alto -9 --ns-treble -7 -Y --noreplaygain (with my version).

Compared to plain -V0 I could ABX improvements with this strategy, as did /mnt recently in his 'Pre-echo Machine' thread against plain CBR320 (see 'Listening tests').

For the current state of Lame I'm convinced this is the way to go for best quality.
lame3995o -Q1.7 --lowpass 17

LAME for VBR, Franhofer for CBR?

Reply #7 –
How long has it been since the latest Fraunhofer update?

LAME for VBR, Franhofer for CBR?

Reply #8 –
Quote from: Rio on
I personally use FhG ACM for CBR encoding (especially on 128kbits/s). It has been a subject of debate on the quality of FhG vs. LAME on CBR. LAME devs have focused on VBR tuning on later versions (3.97 and later), and there has been quite a consensus on LAME regression on CBR on the said versions. http://www.hydrogenaudio.org/forums/index....amp;mode=linear

If I have to use LAME for CBR, I use version 3.90 or 3.93. For newer versions, I set the lowpass at 16kHz.

Please do your own tests. On my personal tests, I prefer FhG ACM for 128 CBR over LAME 3.97 128 CBR (and at other bitrates as well).

In summary, I subscribe to the title of your post. Yes, I use LAME for VBR, FhG for CBR.


I guess I now know why a lot of MP3 files I've come across on the Web were created with old versions of LAME. Interesting.

Quote from: Sylph on
How long has it been since the latest Fraunhofer update?


The last version of the FhG MP3 encoder was released in May 2008.

After messing around with it, I've found that, when it comes to encoding speed, there's virtually no difference between the "fast" (default) and "high quality" setting. When that's the case, I don't know why they just don't use the latter as the default setting. VBR? The highest I've ever got was around 224 kbps, maybe a bit over that. Wonder how that, quality-wise, compares to LAME?

LAME for VBR, Franhofer for CBR?

Reply #9 –
Quote from: RazorBoy143 on
I guess I now know why a lot of MP3 files I've come across on the Web were created with old versions of LAME. Interesting.


Ha!

Don't confuse Scene rules (and to a lesser extent Ubernet rules) with reasoned study of the consequences.

Read up on either of the two ruleset histories and you'll see the correlation with LAME versions found "in the wild".
Creature of habit.

LAME for VBR, Franhofer for CBR?

Reply #11 –
I guess you guys think it's just "coincidence" that when they have a choice, people are choosing to use old LAME encoders to create MP3 files? Some would say that's "confusing" 

Obviously, they know about LAME being dumbed down (thanks to Microsoft) with the --strictly-enforce-iso switch. FhG doesn't have that problem. It does, though, have problems with gapless playback, which is why I think they should use LAME v3.97. From posts I've read, lots of users think it's still the best version of LAME out there, and MP3.

Using the VBR algorithm with the current version of LAME, I think, shows promise. Especially when coupled with the mp3Packer option. Using this method, I was able to create 320 kbps files using VBR V0, with no restrictions on bit reservoir, and saved about %5 on space, with this command line from halb27:

-V0 -b 320 --ns-bass -8 --ns-alto -8 --ns-treble -5 --ns-sfb21 5 --lowpass 16.7

The only question is whether to use the -F switch or not.

LAME for VBR, Franhofer for CBR?

Reply #12 –
Quote
Obviously, they know about LAME being dumbed down (thanks to Microsoft) with the --strictly-enforce-iso switch.

Obviously, they know that bitreservoir size was limited only in 3.98b1... 3.98.2. And current stable version is 3.98.4.

Quote
with this command line from halb27


...then read this: http://www.hydrogenaudio.org/forums/index....st&p=742036

LAME for VBR, Franhofer for CBR?

Reply #13 –
Quote from: RazorBoy143 on
I guess you guys think it's just "coincidence" that when they have a choice, people are choosing to use old LAME encoders to create MP3 files? Some would say that's "confusing"

Again I direct you to the history of the encoding rules adopted by The Scene.  These are easy to find and explain the root cause of much of the confusion out there.
Creature of habit.

LAME for VBR, Franhofer for CBR?

Reply #14 –
Quote from: halb27 on
Quote from: Rio on
... and there has been quite a consensus on LAME regression on CBR on the said versions. http://www.hydrogenaudio.org/forums/index....amp;mode=linear

Thank's for this. Probably I read it when it arrived, but I wasn't aware of it anymore.
As CBR320 is still the recommendation for best quality your link is of vital importance.
The consequence is (up to the day when CBR is implemented again with the same care as has been done with VBR and AFAIK robert is about to do this) that it's best to use the VBR audio coding mechanism also for CBR 320 encodings. robert has shown the way there in the thread above.
With CBR320 there is the advantage that an artificial upper limit for the bitrate isn't necessary as 320 kbps is the highest bitrate anyway. The disadvantage is that standard -V0 produces a bitrate which usually is far below 320 kbps and you don't get the quality you'd expect from 320 kbps (of course you just get the quality of -V0). This is where my usage of -V0 drops in. I use negative values for --ns-bass/--ns-alto/--ns-treble in order to increase the SNR, that is to make -V0 more defensive. With my personal settings I arrive at an average bitrate of 277 kbps but the setting can easily be extended to arrive close to 320 kbps.
Current Lame is a little bit faulty with respect to --ns-treble and --ns-sfb21. That's why I use a variant of Lame 3.98.4 which corrects these faults and optimizes --ns-bass/alto/treble a bit for my purposes.

Those who want to try this special CBR320 approach can use my version.
For those interested in the changes they are here.

For CBR320 I suggest to use a setting like -V0 -b 320 -F --ns-bass -12 --ns-alto -9 --ns-treble -7 -Y --noreplaygain (with my version).

Compared to plain -V0 I could ABX improvements with this strategy, as did /mnt recently in his 'Pre-echo Machine' thread against plain CBR320 (see 'Listening tests').

For the current state of Lame I'm convinced this is the way to go for best quality.


Here's the "Pre-echo Machine" thread halb27 was talking about:

http://www.hydrogenaudio.org/forums/index....77128&st=25

Also, I ended up getting a error message about not having the msvcr100.dll file when I tried to use his LAME 3.98.4m MP3 encoder (won't work without it), so here's a link to that file for anybody else who ends up having the same problem:

http://www.dll-files.com/pop.php?dll=msvcr100

Ripped an album in 320 kbps files using halb27's encoder, then used mp3packer on it to see how much space I'd save. The result? A %6 decrease in file size. Encoding time, though, increased a bit (3:30 with official LAME 3.98.4, 5:00 with halb27's LAME 3.98.4m) But the results are promising. Looking forward to seeing if anymore improvements will follow.

LAME for VBR, Franhofer for CBR?

Reply #15 –
Maybe this thread is interesting for -V0 -b 320 -F --ns-xxx users.
lame3995o -Q1.7 --lowpass 17

LAME for VBR, Franhofer for CBR?

Reply #16 –
CORRECTION: The switches --noreplaygain and -F were inadvertently left out. When included, the command line should look like this:

-V 0 -b 320 -F --ns-bass -12 --ns-alto -9 --ns-treble -7 -Y --noreplaygain

And the msvcr100.dll file should be put into your Systen32 folder. That way, you don't have to have it in the actual encoder location. Use this link to find out where it is on your particular system:

http://www.dll-files.com/pop.php?dll=msvcr100