> > Hi folks, > > (I recently bought a cheap portable MP3 player and (of course) > stumbled over the same problem as Chad Conrad. I then remembered that > my DVD player can play MP3s too, so I checked: same effect. The > portable is a cheap "no name" device; the DVD is a Cyberhome AD-M212 > if anyone wants to know.) > > I think I can confirm the latest news on this: the problem only seems > to show with stereo encoded files with "short blocks". This _includes_ > joint stereo files, since these can IIRC switch to normal stereo > frames to avoid jstereo artifacts. So using -m j lowers the amount of > glitches, but IMHO it does not disable them. But: when I either > disable normal stereo frames (e.g. by using -m f) or short blocks, the > glitches vanish. Other options I tried (without any effect whatsoever) > were: > > --strictly-enforce-iso > --nores > -B 224k > > so it seems the problem is not bitrate and/or bit reservoir dependant. > > I am not around the next week, but if you need an additional tester afterwards, I >will gladly help. I am no good at debugging LAME, however, since I am only mediocre >at C and my MP3 technical knowlege ist quite limited. > > Regards, > Robert
Hi Robert, Can you try with the "-h 5" option? This will disable "best_huffman_divide", which I beleive is the main difference between short blocks in lame 3.70 and later versions. (lame 3.70 is reported to work okay with hardware decoders which have this problem) It is also a feature which is used (as far as I know) by only lame and some FhG encoders which may explain why using other encoders will not create problems. I notice that best_huffman_divide() is specifically disabled for short blocks in MPEG 2/2.5. Does any one remember why this was done? Mark _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
