The stuttering issue - explanation

I've took my time and made a few tests. I recorded some music from a flash-based site (one that preserves the quality of the original files, not crap like youtube sound) using BPM Studio 4.

BPM Studio uses the Fraunhofer MP3 encoder, which is the standard in MP3 encoding (the Fraunhofer Institute created the MP3 format). Original recorded files played back just fine. But when i wrote the tags, this is where stuff gets interesting.

No ID3 tag - no stutter
Tagged using Winamp - stutter at the end
Tagged using BPM Studio - no stutter
Tagged using MP3 Tag Tools - no stutter

So the problem lies in Winamp's tagging engine, not in the encoder, not in the bitrate, not in anything else. Cheap chinese clones don't stutter on Winamp tags, but read them incorrectly, displaying corrupted characters instead of the song name.

Also, sometimes removing tags won't fix the files because Winamp's tags seem to overwrite some of the header info on VBR files. So the Meizu thinks the song is longer than it actually is, resulting in that stuttering sound when the actual end of file is reached.

The fix to this is retagging the problematic files with MP3 Tag Tools, and if that doesn't work either, getting the file reencoded and retagged properly.

Hope this clears you up a bit and fixes all your stuttering songs.

Interesting! Hope a new firmware comes out soon!

Interesting find, it will be great if this theory proves to be true.

Also... I'm not sure what the above poster's point is.

Originally Posted by Err0r

Interesting find, it will be great if this theory proves to be true.

Also... I'm not sure what the above poster's point is.

It's true for me, i've dealt with the crapiness of Winamp tags on my old Actions-based Nano clone, and MP3 Tag Tools fixed all the files, except one which didn't have corrupted characters anymore but displayed the filename instead of the tag on the player, it worked fine on anything else and it works fine on my M6SL too. But the file has been damaged in some way or another, as a proper ID3 tag should display on any device supporting tags.

So it's Winamp giving us all the trouble. Ask the guys over at Nullsoft why.

I don't get the point of the above poster either, it has NOTHING to do with the firmware on the Meizu players. I don't wanna get into details on portable devices, but to keep it short they have much stricter standards to respect coz they need to keep the battery life long. To do this the CPU has to work as effectively as possible.

While on a PC you have plenty of CPU cycles to spare, and it can take the time to make sure your MP3 won't glitch.

I use EZ Tag Editor (free). You can remove all existing tags and add new ones using the database search function. No problems for me.....

Maybe it is true and fraunhofer do not stutter, but should we being forced to use it???
Fraunhofer is not being developed anymore.
LAME encoder is still being actively developed, is free and it got the better encoding- and sound-quality. That’s why so many people use it.
Mp3 encoded with LAME should be fully supported and do not stutter!

I noticed that stuttering is present with no ID3-Tags at all.
Stuttering is still present also with standard-conform ID3v1 Tags written in Mp3tag or foobar2000.
ID3v1 reduces stuttering but should we being forced to use it??? It is 10 years old and limited to 30 characters and does not support unicode!
Newer standards (ID3v2.3 and ID3v2.4) aren’t well supported and cause stuttering.

Well, it has to do with the firmware – mp3-decoder isn’t well written, ID3v2 should be fully supported.

I really don’t care about meizu is developing the M8. They had many time to fix the bugs in firmware since the release of M3/M6.
Due the fact that the firmware causes so much trouble do you really think the firmware of the M8 will be better???

So what if LAME is still in development? IT'S STILL MP3, GOD DAMN IT!!! Fraunhofer set the standard, everybody has to conform to it. What the LAME team does is improve the encoder's speed and fixing any bugs, the format is still the same and they can't make it sound any better.

Contrary to what you say, the Fraunhofer encoder blows away everything else in quality. 192kbps with the Fraunhofer encoder is the most you'll ever need, only lossless audio can sound better than that. I can hear compression artifacts in most 128kbps MP3s, while on the Fraunhofer encoded ones i only detect some attenuation of high frequencies, an overall duller sound than higher quality files. But no artifacts. 320kbps MP3 is pointless, you should use lossless formats instead.

As for ID3 tags, did i mention anywhere that you have to use v1? I hate the limited ID3 v1 too, i use v2.whatever and it works fine if i don't use winamp for tagging.

As for the M8, it will run on windoze mobile. So if something goes wrong on that you can go and bash M$.

EDIT: Here's something. LAME's developers said that themseves.



Since when does "almost" mean "better" ?

Why do you guys always complicate the simplest things.

If the stuttering was only due to the song, then it would happen everytime you played that song, not sometimes. To go even further, it would happen on every other player that played that same file, but it doesn't because the firmware on other devices handle it correctly.

A simple firmware fix will correct this issue. Maybe meizu will consider fixing it, since its not a significant issue as any programmer would agree.

For the software guys out there, they know exactly what I mean.

Meizu should do their homework and that is all.

FhG-codec is not up to date anymore. LAME vbr-presets are definitely the better choice keep yourself informed. CBR is a waste of space.

By the way…LAME 3.12 was made in 1999. Today we have 2008 my friend

Originally Posted by metu

Meizu should do their homework and that is all.

FhG-codec is not up to date anymore. LAME vbr-presets are definitely the better choice keep yourself informed. CBR is a waste of space.

By the way…LAME 3.12 was made in 1999. Today we have 2008 my friend

Amen, brother. Oh, and it was not Fraunhofer Institut who invented mp3, it was the Moving Pictures Expert Group aka MPEG who defined what MPEG-1 Audio Layer 3 aka MP3 would have to be, and brave Fraunhofer have been the first to implement it, flood the market, and revolutionize the way people listen to music. Right now they're working on multichannel audio compression for the next generation surround sound.

By the way, I still get stuttering even without tags. It has been assumed before that this is due to a buffer underflow with vbr mp3s. It occurs only with songs that have no silence at the end, because stuttering silence is still silence.

Great work fraunhofer indeed. But bobby, why do you blame people who want their meizu just working as good as other players?
Do you agree that LAME is a very popular codec and do you agree that it should be fully supported from a meizu?? No?!??!
Ok i see, you really think a mp3 file needs silence at the end that it doesn't stutter. By all respect but such comments are really single sided.

Would've been interesting if tags were really the problem..

Originally Posted by metu

Great work fraunhofer indeed. But bobby, why do you blame people who want their meizu just working as good as other players?
Do you agree that LAME is a very popular codec and do you agree that it should be fully supported from a meizu?? No?!??!
Ok i see, you really think a mp3 file needs silence at the end that it doesn't stutter. By all respect but such comments are really single sided.

huh

I never said such things. This is a BUG , nothing else !
LAME is one of many MPEG1-Layer3-compliant codecs. All of them must be supported if you want to call your device an mp3 player. Quote.
And I never said that you guys should listen only to mp3s with silence at the end. Hey, metu. Where did you get all that from ? I never wrote it.

Originally Posted by BobbyQ

LAME is one of many MPEG1-Layer3-compliant codecs. All of them must be supported if you want to call your device an mp3 player.

Thank you! This is all i wanted to hear.

Would you do me a favour and explain that "buffer underflow"-issue in relation to a flash-based mediaplayer.

Originally Posted by metu

Thank you! This is all i wanted to hear.

Would you do me a favour and explain that "buffer underflow"-issue in relation to a flash-based mediaplayer.

I said it above. The player doesn't recognize the end of the song properly on VBR files, so it runs out of data.

Would someone please do me a favor and send me some stuttering MP3s with no tags?

I'll send you one, with a killing noise at the end. (don't listen to it with volume more than 10 !!!)
Give me your e-mail address.

Originally Posted by Th3_uN1Qu3

I said it above. The player doesn't recognize the end of the song properly on VBR files, so it runs out of data.

Flash-Memory reads up to 60 MByte/s, access time is about 120 µs. I mean there is no way that the buffer runs out of data!
Maybe we can talk about a buffer overflow which is a programming error.

Anyhow, that stuttering-issue do not occur VBR-Files only. But it seems it does occur mp3 files only.




full content here: "End of song bug" test - abi>>forums


Try that song (orginally postet by DaremoS)

http://www.meizume.com/attachments/t...-01-arabia.rar

Be warned this noise gonna blow your ears. Test it with moderate volume only.

About the file: CBR 192, ID3v2, embedded albumart, not encoded with LAME, obviously it has silence at the end
This song plays fine in other mediaplayer.

You can remove ID3-Tags by yourself using Mp3tag or whatever.

metu, would you be so kind to post this information on the English Meizu BBS (along with the link)? Great information, I'm sure they could use it, and try to fix it!
Thanks!

Meizu English BBS

First of all, great info, metu !

Originally Posted by metu

there is no way that the buffer runs out of data!

there is : if you don't reset the block variables that fill your buffer properly, and at the same time miscompute the number of blocks, you will fill the difference of that miscomputation with copies of that last block, resulting in a short loop of the same data --> stuttering.

Originally Posted by Th3_uN1Qu3

Contrary to what you say, the Fraunhofer encoder blows away everything else in quality. 192kbps with the Fraunhofer encoder is the most you'll ever need, only lossless audio can sound better than that. I can hear compression artifacts in most 128kbps MP3s, while on the Fraunhofer encoded ones i only detect some attenuation of high frequencies, an overall duller sound than higher quality files. But no artifacts. 320kbps MP3 is pointless, you should use lossless formats instead.

As for ID3 tags, did i mention anywhere that you have to use v1? I hate the limited ID3 v1 too, i use v2.whatever and it works fine if i don't use winamp for tagging.

As for the M8, it will run on windoze mobile. So if something goes wrong on that you can go and bash M$.

EDIT: Here's something. LAME's developers said that themseves.



Since when does "almost" mean "better" ?

Ehm, Lame 3.12 is ancient. Lame 3.97 (and above) delivers the best sound per bitrate of every mp3 encoder out there. Thus is comes recommended from HydrogenAudio, audiophile community.
LAME - Hydrogenaudio Knowledgebase

LAME (Lame Ain't an MP3 Encoder) is the Hydrogenaudio recommended MP3 encoder. It has been developed by the open-source community since 1998, and has become the highest quality MP3 encoder for most purposes.

Results of MP3 at 128kbit/s Listening Test