Re: Lame-dev Digest, Vol 22, Issue 7

[Simon Howson]

---
        I don't know how variable "variable rate" (or V0) is.  Does V0
have 320 as an upper bound?  I'd assume it would drop to some minimal rate
if, say, there were extended 'simple' sections (ex. a section of 'quiet').

320 Kbps is the upper bound for all the VBR modes, because that's the
largest frame size for the MP3 standard. -V0 is still a variable bitrate
mode, it's just so high that generally it is going to use 256 and 320 Kbps
frames, with maybe 224 and a few 192 on easier passages of music.

All the VBR modes use 32 Kbps for digital silence at the start and end of
songs. So if the CD has been edited with a bit of absolute silence at the
start, you can be assured LAME will compress those sections very heavily.


> I strongly recommend sticking with the -Vx settings, because they have
been
> tested and tuned the most, and are rarely beaten by alternate encoder
> settings.
---
        Any measurable benefit for a -q0 over a -q1?

The default in 3.97 is -q3 because it offers the best quality / encoding
time trade off. Other q settings require a huge trade off in encoding time
for very marginal increases in quality. Here is a test I just did at 128
Kbps CBR:

Q0 2.7 x real time
q1 3.4 x
q2 8.6 x
q3 12.1 x (default setting)

(AMD Athlon 64 X2 4600)

If you want to increase quality, wouldn't it be better to just use the
default q value, but increase the bitrate instead? I.e. use -V3 instead of
-V4?

I have read on Hydrogenaudio.org that some people can hear a difference
between -q3 and -q2 at low bitrates (128 Kbps and lower). However I have not
heard of anyone who can pick a difference between files encoded with q1 and
q2, or q0 and q1. Q3 is 50% faster than q2, so it makes sense to use that as
the default setting.


> LAME doesn't support slicing the files to increase encoding speed.
---
        I know it doesn't support it now, but was thinking of a parallel
version of
bzip2 that did speedup by N-cpu's, but the resulting file
was maybe a couple hundred bytes, or so, more/processor than the
standard version.

Yeah, there is an experimental encoder called LameMT that multi-threads
parts of lame. However it produces files that are far lower quality because
the developer couldn't work out how to multithread some of the more complex
parts of the lame code. From memory LAME MT doesn't use the bit reservoir,
which really cripples how LAME allocates bits, so it isn't surprising that
quality goes down.

If you have a dual core machine, just use Foobar2000 to run multiple
instances of LAME simultaneously. Doing so will get you an effective
doubling of performance without decreasing quality. If you run multiple
instances of LAME in a 4 core CPU, the speed of the hard disc starts to
limit the speed of encoding.

Take care,

Simon




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev

[Linda W-6]

Simon Howson wrote:
> ---
> I don't know how variable "variable rate" (or V0) is.  Does V0
> have 320 as an upper bound?  I'd assume it would drop to some minimal rate
> if, say, there were extended 'simple' sections (ex. a section of 'quiet').
>
> 320 Kbps is the upper bound for all the VBR modes, because that's the
> largest frame size for the MP3 standard. -V0 is still a variable bitrate
> mode, it's just so high that generally it is going to use 256 and 320 Kbps
> frames, with maybe 224 and a few 192 on easier passages of music.
---
        That explains why I see those numbers popping out so often when I I
replay with winamp -- 224 is the one I remember most often, though I remember 192
from some more quiet pieces that were 'slow'.  But off hand, I don't remember if
I encoded them at a higher "V" number (lower quality) or not.

        I've seen 256 some, but don't recall ever seeing a 320 -- but that could be a
peculiarity to Winamp.  That certainly answer my question though -- that V0 will
easily grab 256-320 for any extended period that it would need it (with the low end
being the 32Kbps).  Thanks for the confirming info!

> Any measurable benefit for a -q0 over a -q1?
>
> The default in 3.97 is -q3 because it offers the best quality / encoding
> time trade off. Other q settings require a huge trade off in encoding time
> for very marginal increases in quality. Here is a test I just did at 128
> Kbps CBR:
>
> Q0 2.7 x real time
> q1 3.4 x
> q2 8.6 x
> q3 12.1 x (default setting)

----
        Hmmm...I ran some tests here....and get fairly different results, but
I'm on a Core-2, 2.0GHz. I tested CBR, ABR and VBR, with Q=7,5,3,2,1,0.
With Vbr, which is what I usually use, I get a much smaller difference between
low and high Q, but even on CBR & ABR between Q7->Q0 was only ~4.3-4.6X speed
difference.

        But again, I have the impression, that if you are not streaming, the
VBR settings are "the way to go"....or am I missing something?

My results -- I tried them all 2 ways -- one with -replaygain-fast, and the
other with
replay gain accurate, so there's 2 numbers for each grid location, 1st is RP-fast,
2nd is RP-slow.  I used a standard CD input of a 33MB file.  All numbers are the "x"
number on the far right.

Encode   Q7(F/A)     Q5(F/A)     Q3(F/A)     Q2(F/A)     Q1(F/A)     Q0(F/A)
CBR128  25.4/22.5   15.7/14.5   14.2/13.1   10.3/ 9.7    7.6/ 7.3    5.4/ 5.4
CBR224  24.7/21.5   18.5/16.6   16.9/15.4   14.8/13.5   10.6/10.3    9.9/ 9.3
CBR320  24.4/21.0   18.1/16.3   16.0/14.5   13.9/12.7   10.4/ 9.7    9.5/ 8.8
ABR128  27.7/24.4   16.5/15.2   14.7/13.6   11.6/11.0    7.4/ 7.2    6.3/ 5.9
ABR224  26.4/23.2   19.9/17.5   17.8/16.2   15.9/14.5   11.2/10.7   10.4/10.0
ABR320  26.2/22.5   19.7/17.4   17.3/15.6   15.0/13.7   10.6/ 9.9   10.1/ 9.5
   VBR7  24.0/21.9   22.8/20.9   20.9/19.4   21.0/19.2   20.6/19.4   20.9/19.4
   VBR4  21.2/18.9   20.4/18.2   18.3/16.6   18.3/16.5   18.3/16.6   18.3/16.6
   VBR3  21.2/18.9   20.4/18.2   18.2/16.5   18.2/16.5   18.2/16.5   18.3/16.5
   VBR2  20.8/18.5   19.8/17.8   17.8/16.1   17.8/16.1   17.8/16.1   17.8/16.0
   VBR1  20.6/18.4   19.7/17.4   17.7/16.0   17.7/16.0   17.7/15.6   17.7/16.0
   VBR0  20.7/18.3   19.4/17.5   17.6/15.9   17.6/15.9   17.6/15.9   17.6/15.9

May or may not be obvious, but these are single-threaded numbers.

It *appears* the "Q" value makes very little difference with the VBR (all VBR's
used 'new').  In fact, the difference in timing between Q3->Q0 with the VBR
mode was nearly zero.

If you use fixed-bit rates the Q setting makes a larger difference.  The
accurate-replaygain looks like maybe a 10-15% hit vs. fast-replaygain.

But even at VBR7, Q0 at worst, 15% slower.  It almost appears that with VBR,
the "V" number 'overrides' the "Q" value if the "V" number is lower...?
The real differences come at the more fixed bit rates.

One thing I don't get is how "the VBR" numbers can give an average compression
value at the *start* of the song...  I.e.
V7 -> 14x,
V5 -> 10x
V3 -> 8.2x
V2 -> 7.3x
V1 -> 6.5x
V0 -> 5.7x
--------------
Wouldn't the compression be variable based on the type of music?, up to a best of
4.7x (assuming it used all 320-bit frames).  Seems like the average of 247-248Kbps
is built-in to the calculations -- perhaps that's one of the reasons I thought it
"forced" the compression to a "5.7x" value "Average" -- and that's where my question
about how "variable" "VBR" was.

Sorry for the delay -- wanted to do my own tests, and kepts getting other things
interrupting my test plans...


> Yeah, there is an experimental encoder called LameMT that multi-threads
> parts of lame. However it produces files that are far lower quality because
> the developer couldn't work out how to multithread some of the more complex
> parts of the lame code. From memory LAME MT doesn't use the bit reservoir,
> which really cripples how LAME allocates bits, so it isn't surprising that
> quality goes down.
---
        Ouch!...That would hurt on ABR, though does CBR use a bitres?  Seems
like on VBR, the "difference" in an empty-reservoir could be made up by going
with a few-several high-bit frames until the music "caught up"...but it would
be "tricky"...
        Even on Abr, how big does a reservoir "get"...i.e. if you split the
song in to 2 "subsections, it seems you could use the bitres on each section, but
just have to start at "zero" in the middle (or however many subsections you had
Cores for).
        Knowing nothing about how flexible the bit reservoir is or how long bits can
be carried over, it could be possible after a 1st pass encoding  (and with
mathematics
that would likely be way over my head) to re-encode the first "N" frames of the
split parts using any bits left over from the bit-res in a previous part, and until
the benefit of those extra bits had diminished to "cover" those "break" points where
the 1st pass had to start assuming 0.  .... uh, or am I completely clueless on how
that works? :-)



> If you have a dual core machine, just use Foobar2000 to run multiple
> instances of LAME simultaneously. Doing so will get you an effective
> doubling of performance without decreasing quality. If you run multiple
> instances of LAME in a 4 core CPU, the speed of the hard disc starts to
> limit the speed of encoding.  
----
Guess it depends on your machine, but if you are
encoding 4x 1.412800 Megabit streams, that's only 353.2Kdbytes/second, no?.
Modern disks
can handle quite a bit more than that -- even w/o raid, over 30-40MBytes/second
streaming
isn't difficult to an XFS disk (designed to handle multiple streams of video
going to
disk).  Even at 14MB/s, you'd still handle a 100 times faster than the CPU can
produce.

Do you know if any of the encoding algorithms would benefit from 64-bit
arithmetic or
the newer multi-media instructions?

Thanks for whatever info you have....it lets me know what "could" be done if
someone was
smart enough and motivated enough.  :-)

Thanks again!

-Linda


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev