OK, once again, there is no -b128 bug!!
A typical stereo mp3 frame consists of two granules and 2 channels.
So you have to encode:
granule1 left-channel
granule1 right-channel
granule2 left-channel
granule2 right-channel
That makes 4 possibilities to detect analog silence.
These sections will be encoded with your selected quality
resulting in a need of XYZ bits all together.
Now it goes into packaging these already encoded granules
into a sufficient frame, a frame which provides enough bits.
If analog silence is detected, then all these 4 sections
will be packed into a frame of a lower bitrate then say 128kbits,
but only if XYZ bits will fit into it.
It could also be packed into a frame of a larger bitrate, but
that would make no difference in terms of quality, as these
granules are already encoded and use XYZ bits.
If you force (-F) LAME to use exactly a 128 kbits frame,
this could result in a huge waste of bits on long silent
passages.
Roel, maybe it is time for you to get a version of LAME with
the frame analyzer MP3x included. You would need the GTK dlls
too. Then you can see what LAME does on every frame.
Robert
PS:
analog silence - there is some energy in every band, but
it is below the ATH
digital silence - there is no energy in every band
PPS:
I never use -b n for VBR encodings
Roel VdB schrieb am Die, 11 Jul 2000:
> Hello,
>
> I know I keep going on about this one, but I am reasonably convinced
> something is wrong beside that "analog silence". 386 keeps giving me
> _consistently_ frames below 128k with "-b128" specified. I've been
> told this has to do with analog silence, but there is simply _no
> silence_ in next clip:
>
> http://users.belgacom.net/gc247244/extra/ns.zip (500K)
>
> I don't get it, if there is analog silence detected, the frame should
> be silent (who no 0-frame?), and encoded at 32k, not 96 or 112?? (unless overridden
>by
> "-F") This was the case in previous versions, and I don't understand
> why I keep getting these lower bitrate frames now. There simply is no
> use for -b128 if it is like this.
>
> At -V4 and higher this causes poor results in some encodings, so
> I think overall Q will improve if this is fixed.
Wrong! If -V4 sounds bad, then it is not because of "-b n" and analog silence
detected.
>
> --
> info:
>
> E:\r3mix.net\newsweep\386a>lr -V1 -mj -h -b128 ns.wav ns386a.mp3
> LAME version 3.86 (alpha 1) (www.sulaco.org/mp3)
> Encoding ns.wav to ns386a.mp3
> Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG1 LayerIII ( 6.0x estimated) qval=2
> Frame | CPU/estimated | time/estimated | play/CPU | ETA
> 383/ 383(100%)| 0:00:10/ 0:00:10| 0:00:10/ 0:00:10| 0.9584| 0:00:00
> ----- bitrate statistics -----
> [kbps] frames
> 32 0 (0.0%)
> 40 0 (0.0%)
> 48 0 (0.0%)
> 56 0 (0.0%)
> 64 0 (0.0%)
> 80 0 (0.0%)
> 96 11 (2.9%)
> 112 28 (7.3%)
> 128 37 (9.6%)
> 160 103 (26.8%)
> 192 157 (40.9%)
> 224 48 (12.5%)
> 256 0 (0.0%)
> 320 0 (0.0%)
>
> average: 173 kbs
>
> E:\r3mix.net\newsweep\386a>lame -V1 -mj -h -b128 ns.wav ns385.mp3
> LAME version 3.85 (www.sulaco.org/mp3)
> Win32 binaries from www.chat.ru/~dkutsanov/
> Encoding ns.wav to ns385.mp3
> Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG1 LayerIII ( 6.0x estimated) qval=2
> Frame | CPU/estimated | time/estimated | play/CPU | ETA
> 383/ 383(100%)| 0:00:12/ 0:00:12| 0:00:12/ 0:00:12| 0.8127| 0:00:00
> ----- bitrate statistics -----
> [kbps] frames
> 32 0 (0.0%)
> 40 0 (0.0%)
> 48 0 (0.0%)
> 56 0 (0.0%)
> 64 0 (0.0%)
> 80 0 (0.0%)
> 96 0 (0.0%)
> 112 0 (0.0%)
> 128 121 (31.5%)
> 160 214 (55.7%)
> 192 49 (12.8%)
> 224 0 (0.0%)
> 256 0 (0.0%)
> 320 0 (0.0%)
>
> average: 154 kbs
>
> --
> Best regards,
> Roel mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
