Re: [MP3 ENCODER] the road to next(v4.00?)
Howdy, I tried to search through all the messages related to this topic, but I couldn't find any that addressed the speed issue. Trying VBR using the lastest 3.8 CVS source, VBR is still slower than CBR. Is this still a future improvement, or do I need to set an option? mark stephens In the 3.80 CVS versions, you can enable it with -Y if you want to try it (or download Takehiro's snapshot) but in lame it is still very unstable and not quite as fast as VBR. It uses Robert's latest VBR tunings, some dubious improvements of my own, and does not yet have Takehiro's optimizations. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
Howdy, I tried to search through all the messages related to this topic, but I couldn't find any that addressed the speed issue. Trying VBR using the lastest 3.8 CVS source, VBR is still slower than CBR. Is this still a future improvement, or do I need to set an option? mark stephens - Original Message - From: "Takehiro Tominaga" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 06, 2000 8:15 AM Subject: [MP3 ENCODER] the road to next(v4.00?) Hi all. I'm planning these features to merge the current LAME from my snapshot... ... 2 fast VBR code new algorithm. it is faster than CBR! ... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
Hi, Do the Minidisc players skip like CDs, or do they have a significant read-ahead or otherwise to get around this? I have a Sony Minidisc player that I take out on the boat with me while I am wakeboarding. It takes quite a bit of abuse but I have never heard it skip. Most MiniDisc players have 40-second anti-shock memory. It's usually good enough to take them jogging or cycling, but if you give them a real beating they will skip. Definitely not something I would consider a downside to owning one, as they are much more skip resistant than CD players. Regards, Adam Whitehead CEO - Netherworld Media E-mail: [EMAIL PROTECTED] Phone: +61 (889) 279 898 FAX: +61 (889) 273 889 AudioPhilez (http://www.audiophilez.com) - Original Message - From: "Richard A. Smith" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 13, 2000 11:40 PM Subject: Re: [MP3 ENCODER] the road to next(v4.00?) On Thu, 13 Apr 2000 11:32:55, Shawn Riley wrote: Do the Minidisc players skip like CDs, or do they have a significant read-ahead or otherwise to get around this? I have a Sony Minidisc player that I take out on the boat with me while I am wakeboarding. It takes quite a bit of abuse but I have never heard it skip. -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 Sr. Design Engineerhttp://www.bitworks.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
| OdesÃlatel: Adam Whitehead [EMAIL PROTECTED] | The guitarist in my band uses a Yamaha MD8S to record all our stuff. It | compresses 1 CD's worth of audio down to about 150MB (about 5x compression) | by removing details from the signals that we can't hear (so I assume it | works in much the same way as MP3). It records up to 8 tracks at once as | completely separate entities is supposed to have no noticeable degradation | until the signal's been decompressed/compressed (by bouncing from track to | track) about 1000 times, or something to that effect... Imagine if this | "ATrack" codec was made available for personal computer use, what Yamaha | would want to do to anyone who worked out how to do it... | | ATRAC is the codec used by Minidisc recorders. According to 'experts' it is | not perceptually lossless either. As far as I can remember the bitrate is | 292kbit/s | which is above what people are comfortable with transferring over the | Internet. | | Apparently the latest generation ATRAC (seventh I think) is transparent | to most listeners. Yamaha MD multitrack recorders uses slightly modified ATRAC. When you use MD from SONY, they sound much worse than MD recorded on multitrack from Yamaha. But standard stereo mode sounds same as SONY. Jaroslav Lukesh -- -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
Sony have made a lower bitrate version called ATRAC3 that is available as software. http://www.world.sony.com/Electronics/ATRAC3/ It's used by the Sony Vaio portable music player. According to reviews the encoder uses some encryption so that you can only play back the files on the pc in which they were created. Okay, so I spelt it wrong too... hehehe. Hey, what's this? It can only be played on the pc that created them? So what if a user decides to upgrade? I don't really like the idea of ripping the same 15-or-so CDs every few years because my new computer can't play them! *lol* Is this a joke? I'm sticking w/ MP3 for now :-) Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
Yamaha MD multitrack recorders uses slightly modified ATRAC. When you use MD from SONY, they sound much worse than MD recorded on multitrack from Yamaha. But standard stereo mode sounds same as SONY. Since you normally only record one instrument per track on the MD recorders, I'd expect it to be "easier" to compress. By the way, does that mean Sony players can't play Minidiscs recorded in standard two-track on Yamaha MDx machines? Guess I'll have to take a MD recorded on the Yamaha test it at an electronics shop. Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
On Thu, 13 Apr 2000, Shawn Riley wrote: Okay, so I spelt it wrong too... hehehe. Hey, what's this? It can only be played on the pc that created them? So what if a user decides to upgrade? I don't really like the idea of ripping the same 15-or-so CDs every few years because my new computer can't play them! *lol* Is this a joke? I'm sticking w/ MP3 for now :-) It's no joke. It's a feature of the SDMI (secure digital music initiative). It's scary to think that in the future all portable mp3 players may have this feature. Here's the review that I was referring to. http://members.home.net/timruss/musicclip.html Chris -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
Oops... At 09:13 AM 4/10/00 -0400, Greg wrote: On some samples with mp3, 320k is not transparent to such listeners on any sound equipment What about a mono MP3 sample at 320kBit/sec (vs a mono PCM sample at 705.6kBit/sec)? I guess that defeats the purpose of MP3, but it would be interesting to try... Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
Hi, The guitarist in my band uses a Yamaha MD8S to record all our stuff. It compresses 1 CD's worth of audio down to about 150MB (about 5x compression) by removing details from the signals that we can't hear (so I assume it works in much the same way as MP3). It records up to 8 tracks at once as completely separate entities is supposed to have no noticeable degradation until the signal's been decompressed/compressed (by bouncing from track to track) about 1000 times, or something to that effect... Imagine if this "ATrack" codec was made available for personal computer use, what Yamaha would want to do to anyone who worked out how to do it... ATRAC is the codec used by Minidisc recorders. According to 'experts' it is not perceptually lossless either. As far as I can remember the bitrate is 292kbit/s which is above what people are comfortable with transferring over the Internet. Apparently the latest generation ATRAC (seventh I think) is transparent to most listeners. I don't see why this codec can't be implemented on a PC, but I'm quite sure Sony has a million and a half patents on it. Regards, Adam Whitehead CEO - Netherworld Media E-mail: [EMAIL PROTECTED] Phone: +61 (889) 279 898 FAX: +61 (889) 273 889 AudioPhilez (http://www.audiophilez.com) - Original Message - From: "Shawn Riley" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 11, 2000 4:44 PM Subject: Re: [MP3 ENCODER] the road to next(v4.00?) At 09:13 AM 4/10/00 -0400, Greg wrote: If you are going to make an incompatible format, why not go all the way and fix all of MP3's stupidness. The guitarist in my band uses a Yamaha MD8S to record all our stuff. It compresses 1 CD's worth of audio down to about 150MB (about 5x compression) by removing details from the signals that we can't hear (so I assume it works in much the same way as MP3). It records up to 8 tracks at once as completely separate entities is supposed to have no noticeable degradation until the signal's been decompressed/compressed (by bouncing from track to track) about 1000 times, or something to that effect... Imagine if this "ATrack" codec was made available for personal computer use, what Yamaha would want to do to anyone who worked out how to do it... Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
On Tue, 11 Apr 2000, Adam Whitehead wrote: ATRAC is the codec used by Minidisc recorders. According to 'experts' it is not perceptually lossless either. As far as I can remember the bitrate is 292kbit/s which is above what people are comfortable with transferring over the Internet. Apparently the latest generation ATRAC (seventh I think) is transparent to most listeners. I don't see why this codec can't be implemented on a PC, but I'm quite sure Sony has a million and a half patents on it. Sony have made a lower bitrate version called ATRAC3 that is available as software. http://www.world.sony.com/Electronics/ATRAC3/ It's used by the Sony Vaio portable music player. According to reviews the encoder uses some encryption so that you can only play back the files on the pc in which they were created. Chris Wise -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
wich stupidness are you reffering to? Hahahah :) There's lots of stupid things that mp3 does. It's just an old model designed under considerations that aren't always valid anymore. I don't understand this? Did the physics change, or the human ear/brain? Mark has said a few times that there are several rather obvious things you could change that may increase sound quality. jack. -- Lossless coding is really bad, can be way smaller -- Dynamic range of the scalefactors is much too small -- Short blocks is an awful hack Just look at AAC, it's much better than mpeg-1 Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
I don't understand this? Did the physics change, or the human ear/brain? No. They did not. But the research that the psychoacoustics most encoders used is most likely wrong. Monty has spent a lot of time researching psychoacoustics for vorbis, and has found lots of new research that showed that the old stuff was probably inaccurate. New models for understanding hearing will always emerge, and will require us to rethink the way we are doing things. jack. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
I don't understand this? Did the physics change, or the human ear/brain? No. They did not. But the research that the psychoacoustics most encoders used is most likely wrong. Monty has spent a lot of time researching psychoacoustics for vorbis, and has found lots of new research that showed that the old stuff was probably inaccurate. Well, can this new psychoacoustic model not be implemented in the MP3 format, then? Ivo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
On Sat, 8 Apr 2000, Hudson Kingery wrote: [snip] Has anyone found examples of music that are not transparent at 256k or 320k? I'm referring to transparent on a mid-range home stereo not a high-end studio quality rig. (Mid-range to me is a Denon receiver and Sennheiser 580 headphones. I don't want to start a debate about what is and is not mid-range just wanted to be clear that I wasn't referring to inexpensive soundcards and PC speakers.) [snip] To a 'trained' ear (i.e. someone who's worked on the codec) things are much less transparent then the average joe. On some samples with mp3, 320k is not transparent to such listeners on any sound equipment (I believe that the non-linear responce of lowend PC speakers actually makes it more obvious) IF there are such musical selections and given that CDRs, CDR media and large harddrives are becoming more affordable by the day - has any consideration been given to extending the bitrate up to 384k and 440k? Do the ISO specs allow for this? Could these bitrates be handled by widely available MP3 players? If you are going to make an incompatible format, why not go all the way and fix all of MP3's stupidness. Take a look at vorbis. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
huge snip If you are going to make an incompatible format, why not go all the way and fix all of MP3's stupidness. Take a look at vorbis. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) wich stupidness are you reffering to? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
huge snip If you are going to make an incompatible format, why not go all the way and fix all of MP3's stupidness. Take a look at vorbis. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) wich stupidness are you reffering to? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
wich stupidness are you reffering to? Hahahah :) There's lots of stupid things that mp3 does. It's just an old model designed under considerations that aren't always valid anymore. Mark has said a few times that there are several rather obvious things you could change that may increase sound quality. jack. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] the road to next(v4.00?)
Mark has said a few times that there are several rather obvious things you could change that may increase sound quality. Could these "things" be implemented in an MP3 encoder, or would they need a completely different format? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
IF there are such musical selections and given that CDRs, CDR media and large harddrives are becoming more affordable by the day - has any consideration been given to extending the bitrate up to 384k and 440k? Do the ISO specs allow for this? Could these bitrates be handled by widely available MP3 players? Such high bitrates are allowed, but are required to be constant bitrate only. About the players, I don't know as mp3 players are not required to be able to play free bitrates, and I never seen any encoder producing free bitrate. Regards, Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
From: "Hudson Kingery" [EMAIL PROTECTED] Has anyone found examples of music that are not transparent at 256k or 320k? castanets.wav and fatboy.wav on the LAME web page. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
I would like to see quality as the number 1 priority, especially at higher bitrates. Ease of code improvement and maintenance as the 2nd priority. Speed as a very distant 3rd. Additional features not related to quality as 4th. Has anyone found examples of music that are not transparent at 256k or 320k? I'm referring to transparent on a mid-range home stereo not a high-end studio quality rig. (Mid-range to me is a Denon receiver and Sennheiser 580 headphones. I don't want to start a debate about what is and is not mid-range just wanted to be clear that I wasn't referring to inexpensive soundcards and PC speakers.) IF there are such musical selections and given that CDRs, CDR media and large harddrives are becoming more affordable by the day - has any consideration been given to extending the bitrate up to 384k and 440k? Do the ISO specs allow for this? Could these bitrates be handled by widely available MP3 players? Thanks to all the LAME contributors. I have been very impressed by your dedication and skills. Hudson At 08:50 PM 4/6/00 +0900, you wrote: Hi all. I'm planning these features to merge the current LAME from my snapshot... 0 new bitstream handling code (this is almost done by Mark) 1 new short block lossless compression and bit allocation 2 fast VBR code new algorithm. it is faster than CBR! 3 new window subband code little bit faster 4 many ix86 assembler routine some from GOGO, some from myself. 5 new noise shaping algorithm, including subblock_gain and scalefactor_scale I'm planning some 3D Now!, SSE code, but I have no K6-2/3, Athlon, PIII. does someone donate me a machine or shell account :-) ? and these have not written yet, but may improve the LAME 5 mixed_block support 6 call best huffman code each iteration maybe very very slow, but quality will be up. Any ideas ? or does someone doing part of them ? --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
Zia Mazhar wrote: But depending on how slow this will actually be, it maybe not always be desired, so I'm not sure if this should make the difference between a --quality 8 or --quality 9 (9 being the maximum) option, if you know what I mean. I think a different switch should be fixed for this, like -eh [extra high quality]. But isn't --quality just a more detailde -h ? --quality 0 -- no -h option --quality 6 -- -h --quality 9 -- your -eh option and some in between david balazic -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
From [EMAIL PROTECTED] Thu Apr 6 22:15:19 2000 .. To: [EMAIL PROTECTED] .. From: Takehiro Tominaga [EMAIL PROTECTED] .. I'm planning these features to merge the current LAME from my snapshot... .. 4 many ix86 assembler routine .. Takehiro, Many of us care little about encoder speed and are much more concerned with encoder quality. For us, the addition of assembler routines just further obfuscates the code. If you must, at least leave the C code in place but #defined out so as to serve as the code's specification (and as a useful check of correct functioning and as a first step for people who want to run lame on other architectures). Your other, architecture-neutral changes sound good (as long as they don't break it :-)). Regards, Bruce Janson, Basser Department of Computer Email: [EMAIL PROTECTED] Science, F09 Madsen Building, Eastern AvenuePhone: +61-2-9351-3423/4 University of Sydney, N.S.W., 2006, AUSTRALIA Fax:+61-2-9351-3838 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
But depending on how slow this will actually be, it maybe not always be desired, so I'm not sure if this should make the difference between a --quality 8 or --quality 9 (9 being the maximum) option, if you know what I mean. I think a different switch should be fixed for this, like -eh [extra high quality]. But isn't --quality just a more detailde -h ? --quality 0 -- no -h option --quality 6 -- -h --quality 9 -- your -eh option and some in between Yeah, you would say so, but depending on how slow is it, and the extra quality you will get in return for it, it may be a bit deluding, since some people will want the highest quality and then claim lame to be very very slow, because they just tried maximum quality, while lame without the new huffman stuff (I suck at technical MP3 knowledge ;)) might do almost exactly the same, but very much faster. But I don't know how big the difference in speed/quality will be. It's just a thought. Dismiss it if everone thinks differently ;) Ivo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
"Segher" == Segher Boessenkool [EMAIL PROTECTED] writes: I'm planning some 3D Now!, SSE code, but I have no K6-2/3, Athlon, PIII. does someone donate me a machine or shell account :-) ? 3D now and SSE are fine, but why not some MMX code? A lot more people got mmx processors. Are 3D Now and SSE really faster than MMX? Segher MMX is integer, 3dnow is float. and 90% of MP3 encoding process is floating point calculation. rest 10% is integer, like lossless compression (Huffman coding) But they are hard to vectrize... so we can speed up the MP3 encoding only little bit using MMX. "Scott" == Scott Manley [EMAIL PROTECTED] writes: Scott MMX will have a lot of use in getting the input data to the Scott correct sample rate etc, I can see real uses for it there. right, resampling is one thing we can use the MMX, but the lagest problem of MMX command set is that there's only 16bit multiply. --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
I'm planning some 3D Now!, SSE code, but I have no K6-2/3, Athlon, PIII. does someone donate me a machine or shell account :-) ? 3D now and SSE are fine, but why not some MMX code? A lot more people got mmx processors. Are 3D Now and SSE really faster than MMX? MMX is integer, 3dnow is float. and these have not written yet, but may improve the LAME 5 mixed_block support Thus Lame would be the first encoder able to produce mixed blocks FhG does as well. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
6 call best huffman code each iteration maybe very very slow, but quality will be up. This could be called only in the highest quality setting, like in mp3enc, when quality setting will be implemented But depending on how slow this will actually be, it maybe not always be desired, so I'm not sure if this should make the difference between a --quality 8 or --quality 9 (9 being the maximum) option, if you know what I mean. Any ideas ? or does someone doing part of them ? I'm planning to write an extension to the --preset option: loading presets from a file. Does anyone think that it's usefull or useless? I think this would be a very useful feature. Ivo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
From: Takehiro Tominaga [EMAIL PROTECTED] Date: Thu, 06 Apr 2000 20:50:25 +0900 Hi all. I'm planning these features to merge the current LAME from my snapshot... 0 new bitstream handling code (this is almost done by Mark) This is almost done. The new code works great except for a bug in the framesize for VBR streams. I hope to test a little more and check it in today. In the process I found (one of) the MPEG2.5 8khz bug: region1Start = 12 for short blocks is used throughout the code, but it should be region1Start=scalefac_band.s[3], which is not always 12! The new code (except for a few variables which still need to be changed) is also "thread" safe, so it looks a little different. All the global variables have ugly "gfc-"'s in front of them. 1 new short block lossless compression and bit allocation I actually put this in yesterday, but didn't re-order ix, which of course didn't work but at least I got far enough to understand why ix has to be re-ordered! I will stop working on it, but let me use this as an example of how I think we need to proceed: I tend to be *very* conservative on changes like this. I would prefer to first implement the following way: 1. new short block compression code, which re-orders ix on-the-fly. option to use old values of bigvalues, count1. 2 Run through my test suite: make sure new code with bigvalues=count1=576 still works. (check that results identical) 3. Run code with new bigvalues and count1 region, but with --nores. Results should be identical *except* for short blocks. check this. 4. Run new code, create new test cases. 5. re-order ix, chance calc_noise, calc_xmin, retest. should produce identical results, but may not because the order of operations has changed. If not, test with --nores and expect 1% differences. Regenerate test cases. 2 fast VBR code new algorithm. it is faster than CBR! I just have one favor to ask related to this: I would like to use the noise shapping routines (choice of scalefactors) in vbrquantize. This code should be done in another day or two. I know you had this in your version a long time ago, but vbrquantize.c is my "pet project". Also, your code is so efficient it was hard to understant :-). I have to first put something in that I fully understand, and then we can start optimizing. From a mathematical point of view this algorithm is much better in that it does noise shapping as close as possible to the psycho acousticts. The ISO code appears to be a very ad-hoc algorithm which seems to give good results. It chooses scalefactors in an slow, gradual amplification process, but this may somehow be magically tuned for the ISO masking data. I doubt it, but it is possible that the ISO algorithm will give better results. Comparing the two codes will also be hard, since these effects are subtle and require lots of listening. I am assuming the new code is going to be better, and in that case it will also be used for CBR, where we adjust the maskings (a la Robert's VBR work) not to obtain a desired quality but to obtain a desired bitrate. Anyway, because of all this, it is very important to me that I feel I know exactly what is going on in the choice of every single scalefactor in vbrquauntize.c! 5 mixed_block support Funny you should mention that. When I was getting bitstream.c to work in LAME, i saw that old #ifdef ALLOW_MIXED and thought this code is never going to be used and deleted it :-) Anyway, it is still in CVS. I dont recall evern seeing *any* encoder make use of this: the frame analyzer will display "short (mixed)" if the short block is of mixed type. Of course the fact that I've never seen this may be that the frame analizer has a bug in it :-) Does anyone have a mp3 that they know uses mixed blocks? Some comments: short blocks are used 10% of the time, and if mixed_blocks were used in 10% of those, we are down to a 1% effect. If you just allocated more bits these 1% of the cases, you would probably get better results and only increase the filesize by a tiny ammount. Other problem: what is the algorithm to determine when to use a short block instead of a mixed block? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
