OK, Let's Fix This

I've been using the M6 for more than a year now but don't seem to have the problems constantly complained about here.

I'm tired of it, so let's fix this stuff once and for all. Let's list the problems comprehensively, and I'll personally address them to Meizu.

I had a look at the wishlist thread, but there is just too much there. For now, what's most important is that the critical bugs are fixed.

Now, what are they?

1. MP3 end of song stutter - Does this happen all the time, only on VBR, or what? Does anyone really know more about this?

Great idea ErrOr

One of the things that surprised me about the forum was the lack of a centralized bug list.
(other than the Whishlist)
A centralized bug tracking point it's a must.
It should be very visible, maybe a sticky or even a subforum?

(BTW a wiki would be great for bug discusion and general reference)

Not only should this facilitate things for Meizu, but especially for the other users, that way they could have a centralized and updated point to look for common bugs before posting a new thread.

We should differentiate very well bugs from "design suggestions" or improvements. Failure to to so tends to result in unproductive discussions.

We also should try do describe the bug to avoid duplicates.

So here is my small contribution:

2- 128 tracks per artist limit in the library
3- 2048 track limit in the library.
3- proper tag indexing.
4- Fix Vbr support.

Thanks for the idea and for this great site.

2 & 3 - Anyone know what the limits are on other brand MP3 players?

3(4) - What's wrong?

4(5) - Again, let's describe the exact problem.

compatible with playsforsure

Sorry, I had to write quick

1) The 128 track limit is a totally new experience for me, I don't know of any other instance in the DAP market. Basically the library will not index more than 128 tracks for any given artist name.

2) The 2048 absolute limit appears to be more common. Programmers didn't foresee the exponential growth in storage capacity. Their code lacks scalability.

3) Tag indexing, it's a minor bug but there are random mistakes when reading id3 tags (while there is nothing wrong with the tags themselves).

So what do you think about the wiki, do you think it's a got idea?
we could assign each bug a number link and create create an entry describing each bug.

2 & 3 - Anyone know what the limits are on other brand MP3 players?

The Cowon D2 has a 500 folder 5000 file limit.

Re VBR: Not a problem I had encountered in normal use but was able to create the occasional stutter by ripping VBR (New VBR mode) encoded files using highest possible settings from live\studio albums that have no silence at the end of tracks.
However I did not encounter a single stutter problems after ripping 6 live albums using Old VBR mode even with the sample rate cranked up to 48Hz.

How about trying to figure out why so many players seem to just die for no reason in various ways. What is making the code so unstable that this can even occur? I have seen posts stating theirs just die while playing music, when a song ends it just turns off for good, it dies when being unplugged from USB at times, they sometimes screw up playing a video or music file, and mine died for good just playing a song, and then turning off by itself, then after I got it running again and paused and played a few times in a row, it was gone for good after some major error I can't even identify.

I can't state it any more clearer than just find out why the code is so unstable to allow permanent or nearly permanent deaths for seemingly no reason. Has anyone else ever even seen another DAP do things like this, because I haven't, and never heard of a case of it. The most I've ever heard is having to push the built in reset button and everything's back to normal without even erasing all your files.

I really can't say for sure what file types this end of song bug occur on, because some have stated they got it on CBR music as well. The thing that makes the bug "visible" is when there's no ending silence, and everyone confirms that no other player has that problem, so there's no reason for the M6 to. As for the music it happens to on mine, those aren't even encoded at a high bitrate, they are VBR recordings of Nintendo music, and are mostly at a rate of between 32Kbps to 240Kbps occasionally.

Umm... fix the menu button itself instead of doing this somewhat annoying fix? My TP is an older player, and the menu button was used a lot... about 50 times a day as I constantly would keep going through and changing what songs I wanted to listen to at work, and I played boxman a lot. It hasn't even shown a hint of failure.

Definitely fix the file, folder, and playlist limits for the 8GB players.

Fix the spectrum analyzer so it isn't barely visible, and so it works with flac files.

Make it a bit easier to use album art, though it isn't that important. It should be able to tell the album art just by it existing in the folder the music is in.

Make it so that custom backgrounds don't create a bitmap image in bin format out of an image of 1/10 the size that's already there. No idea why they so that. Not too important, either, but notable.

More later.

- I also have the end of track bug. CBR or VBR, same issue. Pretty annoying but not to the point of ruining my day.

- Fix tag reading : some albums have their songs displayed in the wrong order. I've tried erasing / reconstructing the id3 tags, nothing seems to do the trick. Kind of irritating to expect a song to come after another one and get some other one from the album instead.

- Album art : why the hell did we have to search for 2 entire weeks how to make it work ? Is it too difficult to have the M6 look for "album.jpg" in the album folder ? That's the standard everyone uses, why should Meizu want to gather all album arts in one folder ?

- We all know the Spectrum Analyzer has its opacity reversed. Opaque text => transparent Analyzer. Opaque Analyzer => transparent text ..

(and one last requirement to rule them all... open your firmware already ...)

Originally Posted by DChronos

How about trying to figure out why so many players seem to just die for no reason in various ways.

This is really not helpful.

I've gone through more than a dozen players, none of which died for no reason.

What we want to do here is compile a list of urgent problems that can be fixed quickly.

Mp3 reading errors...that whole thumping reverberation thing. Having it happen when listening to my songs (or not paying attention at the time) really hurts my ears badly. I don't understand why as my other players and computer can read the songs fine. I don't use vbr.

The song library rebuilding process is an incredibly poor method of gathering files, it is worsened by the fact that it happens every time I unplug the player from USB. I have never had a player that does it like this. I believe its due to not understanding a proper way of doing it.
If the developers cannot work around the process without totally rewriting the code, then perhaps make it happen invisibly. Like to only build the song list on top of the old one, only finding new songs, so that the new songs are added gradually after the player is turned on (but the player still functions normally while this happens).

The need to rebuild the song library if the player is shut down improperly doesn't make too much sense to me. Ex1, I have the player set to lock when I turn on the player, when I restart without the keylock, the library needs to rebuild....Why? Ex2, when the player shuts off expectantly like battery dying.

In terms of *major* bugs, thats all I can really think of.

ScottyGEE, can you send me a few songs where you have that problem? My email is the same as my MSN.

The auto-update is a major annoyance for me too. I was told they had to do that after adding MTP support.

I second that, Err0r !

Additionally, I suggest the following :
1. create a new bug section in the forum
2. create sub categories like video, audio, pictures, other etc.
3. let the people submit new bugs themselves, sorted in the right category (this needs to be moderated) and add the poll feature with the following options :

• reproducable every time
• happens sometimes under unknown conditions
• happens sometimes under specific conditions
• doesn't happen at all for me

4. if anybody has the same problem, he or she can vote in the poll, and reply in the corresponding thread to give additional information and discuss the bug to a degree.

If we do this right, we can count the number of votes, and get an idea of how urgent and reproducable the specific bug or problem is.
The upside of this would be that we can use the tools of this forum and need no other software.

Meizu.com should support us with this in any way they can, because we are making their products better for free ! I wonder why the CEO has not yet made any serious attempts to lend a helping hand.

Originally Posted by BKeeper

3) Tag indexing, it's a minor bug but there are random mistakes when reading id3 tags (while there is nothing wrong with the tags themselves).

Does this happen on all your tags? I've only encountered problems with the album-tag in OGG and FLAC-files.
Ex. 'David Gray' - 'Babylon' from the album 'White Ladder' became
'David Gray' - 'Babylon' from album 'White Ladder Gray' (OGG)
and
'Fall Out Boy' - 'Thnks Fr Th Mmrs' from 'Infinity On High' became
'Fall Out Boy' - 'Thnks Fr Th Mmrs' from 'Infinity On HighBoy' (FLAC)

Adding blank-spaces at the end of album-tags doesn't fix it either...

EDIT: I've managed to find the problem. It's the 'Album Artist'-tag.

If I added spaces at the end of the album name, the M6 indexed it as album 'ARTIST=David Gray', which is NOT the artist tag, but the album artist-tag.

If there is something wrong with the album-tag (for instance, blank spaces at the end), it simply continues and thinks that it has found the album name when it finds 'Album Artist=David Gray'.
And if both tags are functional, it reads both and writes the shortest one on top of the other.

Short-term fix: Remove the 'Album Artist'-tag on all your Flac's and Ogg's

Maybe a tad off-topic but here it goes:

I've been working on changing the profiles-code of MEncoder for Xvid to create an M6-profile. (And possibly M3, but being limited to trying it out every time I make a change: I don't have an M3) With this profile it would be possible to encode a video with the Xvid-codec in the highest possible quality without any stuttering because the encoder keeps track of the decoder's available resources etc. Experimenting wih all the parameters is a pain in the arse and takes time. (Small samples say nothing, it are the big ones with most of the problems)

If Meizu could answer at least some of these things about their MPEG4-decoder in the M6 (And if possible M3), it would speed things up incredibly.

1) What is the maximum bitstream memory available for each Video Object Layer? (VBV)
2) How many MacroBlocks can the decoder decode each second? (VCV in macroblocks a second)
3) What is the maximum number of decoded MacroBlocks that the decoder can store during the decoding process of all Video Object Layers in the scene? (VMV buffer size in MacroBlocks)
4) Has the maximum video bitrate, which was 512 kbit/s according to the site, changed now that a framerate of 20 fps is available.
5) Is the decoder capable of decoding 4MV well at high bitrates, or is it better to turn 4MV off when encoding at high bitrates?

That would be all. :P At least I and BobbyQ would thank Meizu gratefully if they could provide us with this info.

And offcourse we would thank Err0r if he could address this to Meizu together with the rest of the issues mentioned in this topic!

For me the 'end of song stuttering' bug only happens when there is no silence at the beginning of the track. I can hear the player repeating the first second of the finished song when it is switching tracks.

Another bug that really needs to be fixed is the hissing on low impedance earphones. On my 20ohm Vsonics it gets quite annoying at the low volumes I normally listen at (around 6). I've observed this 'white noise' stays at a constant level when the volume is above 0, but disappears at volume 0. It also stops temporarily when the player is changing tracks, but immediately returns once the song begins. This makes most canalphones unsuitable for use on the m6, unless of course you turn the volume to drown out the hiss, but then that defeats the purpose of canalphones .

ylac

Originally Posted by Robin

Does this happen on all your tags? I've only encountered problems with the album-tag in OGG and FLAC-files.
Ex. 'David Gray' - 'Babylon' from the album 'White Ladder' became
'David Gray' - 'Babylon' from album 'White Ladder Gray' (OGG)
and
'Fall Out Boy' - 'Thnks Fr Th Mmrs' from 'Infinity On High' became
'Fall Out Boy' - 'Thnks Fr Th Mmrs' from 'Infinity On HighBoy' (FLAC)

Adding blank-spaces at the end of album-tags doesn't fix it either...

EDIT: I've managed to find the problem. It's the 'Album Artist'-tag.

If I added spaces at the end of the album name, the M6 indexed it as album 'ARTIST=David Gray', which is NOT the artist tag, but the album artist-tag.

If there is something wrong with the album-tag (for instance, blank spaces at the end), it simply continues and thinks that it has found the album name when it finds 'Album Artist=David Gray'.
And if both tags are functional, it reads both and writes the shortest one on top of the other.

Short-term fix: Remove the 'Album Artist'-tag on all your Flac's and Ogg's

This one has got to go on the list as it is particularly annoying for me since I tag all my compilation albums with an Album Artist of "Various Artists", while setting the artist tag for each individual track artist.

The album list view becomes very messy if I have compilations in there. It just seems to read the Album Artist tag and writes it into the memory of the previously read Album tag, causing an overlap.

I have mentioned this before here: http://www.meizume.com/firmware/915-wishlist-firmware-2-003-a-post10740.html#post10740


Another thing to mention is that the player will sometimes shut itself off after finishing playing a track. Only happens very rarely though, and I haven't kept track of whether it happened on particular tracks or not.

Originally Posted by Err0r

1. MP3 end of song stutter - Does this happen all the time, only on VBR, or what? Does anyone really know more about this?

I do not have any song related problems, except for the hiss issue. I have Mp3's, and WMA in both VBR and CBR formats. Some people say on live songs, but I have those too, and don't have any problems with them. Hissing and the video lags are the biggest problems for me.

Hi everyone this is my first message here; I decided to join in when I saw this interesting thread.
This is what I experience:
-repeating end of the track (annoying when album tracks are continuous)
-if I play a whole album from the library the song order depends on the title of the song instead of considering the track number or the file name; i found an option that should change it but it didn't work for me (I usually use the browser because of this)
-when i pasted a new album on the player the first track was substituted by another track on a completely different directory. I solved it by deleting the track that was played instead and re-pasted it. The song that was substituted was still on the player, but it didn't read it. This only happened twice
I guess it might be useful to say that the firmware version is the 2.002.3 (I didn't upgrade because I was waiting for a version that fixed my problems)
and that all my tracks are stereo mp3s at 64kbps cbr.
Hope it helped

Try uprading, it might fix some of your problems.

hmmm, well i myself find this a huge problem, the hissing, maybe they can try to increase the snr once again