First I have to thank for the new firmware features (and hopefully the full_volume_at_songchange bug fix)!
My problem is(was), that the fuze froze at the database rebuild after installing the new firmware. I removed all music and copied it back on the fuze album-by-album and found the hang is caused by OGG files that didn’t cause problems with the .22 firmware.
The problematic OGG files have been tagged using MusicBrainz Picard, ver. 0.11, under linux. Removing all metadata from the OGG files solves the DB update problem.
Later I found the vorbissort script mentioned here
that also cures the database update problem and allows to keep all tags. (BTW: the vorbissort was written to solve problems regarding coverart in the tags, which I don’t use.)
It seems that MusicBrainz Picard writes the tags in a way that confuses the fuze, even though the Picard tagged OGGs play flawlessly in several software players on my PC.
I had a similar issue with one of my fuzes. I haven’t reloaded my player yet to determine which file or files caused the problem. (99.9% of all my files are encoded using ogg vorbis). My computer is windows based and have used a variety of programs to encode and make tags.
I have used a couple of suspect encoder programs to test thier functionality, and my hunch is that these files found their way onto the fuze in question.
I too have suffered this problem. It too me ages to find the offending OGG files, but now having reconverted them (using a slightly different q value to ensure the files were a different size) the problem has disappeared.
It would have been nice for the files to have been rejected/ignored or otherwise flagged (please Sandisk!).
These files all played perfectly under the previous firmware.
that also cures the database update problem and allows to keep all tags. (BTW: the vorbissort was written to solve problems regarding coverart in the tags, which I don’t use.)
It seems that MusicBrainz Picard writes the tags in a way that confuses the fuze, even though the Picard tagged OGGs play flawlessly in several software players on my PC.
That’s very interesting. All vorbissort is (supposed to be) doing is moving the “coverart” comment—which contains an encoded jpeg, basically, as far as I can tell—to the end. What I found is that the Fuze would stop reading Vorbis comments when it saw this one, leading to indeterminate tagging.
If you do a vorbiscomment file.ogg on a troublesome file, is there a line that begins with “coverart”?
If vorbissort is somehow fixing Vorbis files that don’t have coverart comments in them, Picard might be writing things out in a weird fashion that the stock vorbiscomment utility does not. Now I’m curious!
no, my ogg files don’t contain coverart, I checked once again. The solution is just to rewrite the same tags with vorbiscomment. I also diffed the vorbiscomment output before and after rewriting the tags and found no differences.
Picard is cross platform (written in Python). Thus I suspect it uses its own tag writing functions in contrast to vorbiscomment that uses libvorbis. Either Picard is doing something wrong or the Fuze firmware. But Picard tagged files run smoothly with several software players…
