What about the idea to allow the user to code the file in two passes
for the very best quality by the extense of doubling the CPU time.
1st pass with "--hintfile":
________
WAV --->| |---> MP3 (first pass quality)
| LAME |
| |---> HINT
~~~~~~~~
2nd pass with "--usehintfile"
________
WAV ----| |---> MP3 (first pass quality)
| LAME |
HINT -->| |---> HINT (unused)
~~~~~~~~
In the hint file for instance one byte per frame is stored:
Bit 7:4 Should MS or LR coding be used?
0 no info
1 very strong buy for LR stereo br(LR) <= 0.545 br(MS)
...
8 no differce br(LR) == br(MS)
...
15 very strong buy for MS stereo br(LR) >= 1.834 br(MS)
Bit 3:0 Bitrate demand for the best coding
0 no info
1 low bit rate demand < 20%
...
5 normal bit rate demand 100%
...
15 very high bit rate demand > 300%
MS/LR switching can be optimized in a seconds pass.
Also the bit reservoir can be better balanced.
You can empty the bit reservoir for an attack if there are following some
silent milliseconds of music
5 5 5 8 10 3 2 4 4 3 4)
^
empty bit pool here for best Q
But may be the attack is followed by a much more worse attack
5 5 5 8 10 14 3 2 4 4 3 4
^ ^
| empty the bit pool here
and not here
The same efect can be achieved by increasing the latency time of lame
so lame can see more of the music' future.
Proposal
Application feed samples via lame_encode_buffer() to lame.
lame collects the samples in an overlapping circular buffer�)
with an size of for instance 8192 samples. Every function
(gpsycho, lame encoder, MS/LR detection, ...) gets the same
big data block, but everyone are interested of another area
of the data:
|----------------------------------|
MS/LR ^^^^^^^^^^^^^^^^^^^^^^^^^^^
gpsycho ^^^^^^
coder ^^^^^
coder ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (out of bit scenario)
--
Mit freundlichen Gr��en
Frank Klemm
�) circular overlapping buffer
Two successive buffers are filled with the same data.
| 1 2 3 4 5 6 7 8||1 2 3 4 5 6 7 8|
|--------------------|
| 9 10 3 4 5 6 7 8||9 10 3 4 5 6 7 8|
|--------------------|
| 9 10 11 12 13 6 7 8||9 10 11 12 13 6 7 8|
|--------------------|
Advantage: No wrapping
Disadvantage: Needs some 10^-2 MByte of RAM
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721 home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
