Re: [MP3 ENCODER] Multi Pass MP3 Encoder
On Tue, 5 Sep 2000, Greg Wooledge wrote: Frank Klemm ([EMAIL PROTECTED]) wrote: 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. This has the obvious disadvantage of not being possible when reading from a pipeline. But as a user I would definitely use this option if it were offered. In a pipeline it can store the file temporarily. Either in memory or /tmp. Mark Powell - UNIX System Administrator - The University of Salford Academic Information Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi Pass MP3 Encoder
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. Some video encoders (ex: mpeg-2 media cleaner encoder) are using 2 pass encoding, and it seems to substancially improve the output MS/LR switching can be optimized in a seconds pass. Also the bit reservoir can be better balanced. About the bit reservoir, I understand, but for the m/s switching, I don't understand how multi-pass would help. Another thing is that multipass would allow VBR with a predictible file size. But I also suspect that multipass would need a lot of coding. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Multi Pass MP3 Encoder
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-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi Pass MP3 Encoder
Frank Klemm ([EMAIL PROTECTED]) wrote: 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. This has the obvious disadvantage of not being possible when reading from a pipeline. But as a user I would definitely use this option if it were offered. -- Greg Wooledge| "Truth belongs to everybody." [EMAIL PROTECTED] | Red Hot Chili Peppers http://www.kellnet.com/wooledge/ | PGP signature
