Seemingly valid MP3 crashes player

SanDisk MP3 players All other MP3 players
1

Sansa Clip Zip.  Updated firmware today to 21a.

The MP3 can be found at https://docs.google.com/file/d/0BzzWvVASPpXSTmtkSy1fM0F5OW8/edit?usp=sharing

I would have sent you a short MP3, but when updating the playlists, the player apparently ignores short files ( @#$@#$# WHY???), so I couldn’t tell if my short MP3 would also crash the player.

This MP3 was created with the avconv utility on XUbuntu Linux 12.04.  I have created lots of MP3s using the ffmpeg utility on Puppy Linux v5 and they have all worked fine in this player.  However the overwhelming majority (but not all) of the MP3s created by XUbuntu 12.04 either cause the player to lock up or to restart.  If I use Puppy Linux v5 to re-encode the MP3, the player will play it.

My first thought was that there was a defect in XUbuntu’s software.  However I took an MP3 that crashes the player and successfully played it in these environments:

   * Puppy Linux v5

   * Windows XP Media Player

   * Windows ME Media Player and WinAmp Media Player

   * LUbuntu Linux 13.04

Usually the player crashes right as soon as I start playing the MP3, BUT NOT ALWAYS.  In a couple of instances there have been files that crashed the player in the middle or at the very end of a tune.

Changing the header format to ID3v2.3 didn’t help.  Nor did changing the header format to ID3v1.  Removing the metadata doesn’t help either.  In one case I did get a change of behavior (restart instead of lock up) when I switched from ID3v2 to ID3v1, but that could be just a random manifestation of another error.

So, I tried to switch to Ogg/flac format.  No luck there either.  Placing such a file on the player caused it to lock up while updating the playlist.  Ogg/vorbis format seems to work OK.

2

Bitstream of that file looks normal and parses fine as far as I can tell. I’d guess its not directly related to the mp3, maybe file system corruption? Try checking the disk for errors in MSC mode. FYI, FLAC has its own container rather than Ogg. You can of course put FLAC in Ogg (its a generic container and will store almost anything), but this is not standard and most software will not understand the resulting file. FWIW, if you’re using linux and like Ogg/FLAC, you may be interested in rockbox. Its an open source operating system that runs on the clip and has much better support for alternate file formats like Ogg, FLAC, AAC, etc.

3

Structure of the flash drive appears to be OK.

fsck.vfat -n /dev/sdb
dosfsck 3.0.14, 23 Jan 2023, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  3:2e/4d, 4:7c/53, 5:64/44, 6:39/4f, 7:5c/53, 8:49/35, 9:48/2e, 10:43/30
  Not automatically fixing this.
FATs differ but appear to be intact. Using first FAT.
Leaving file system unchanged.
/dev/sdb: 507 files, 555847/958507 clusters

Another Ubuntu user had the same problem with the Sansa Clip+

See http://ubuntuforums.org/archive/index.php/t-2103269.html

So I downloaded the latest version of ffmpeg directly from ppa:jon-severinsson/ffmpeg and re-encoded the offending MP3.  While doing so I got an error message: “Truncating packet of size 1024 to 547” BUT THE RESULT DID NOT IMMEDIATELY CRASH THE PLAYER (though I didn’t play it all the way through).

I tried using the “-packetsize nnn” option to avconv to no avail.  This option appears to be ignored, at least for MP3.

Next, I used avconv’s -dump feature to dump the created MP3s in hex and found that the MP3s created by the two versions of ffmpeg/avconv are structured very differently.  The one that crashes the player appears to be structured in blocks of 626 bytes while the one that works is structured in blocks of 209 bytes.  Interestingly, the one that worked also compressed much better than the one that didn’t.  However 626 is still less than 1024, so I’m not sure what relationship this has to the error message.

I’ve posted the MP3s along with the hex dumps and the original .wav file at.

https://docs.google.com/file/d/0BzzWvVASPpXScTFUZDF0OFZEUG8/edit?usp=sharing

All these files, by the way, CAME OFF THE PLAYER, so if there is a problem with corruption of the flash drive, the files should appear corrupted to Linux as well.

I’d blame ffmpeg but again, the files that crash the player DON’T crash computer based media players going all the way back to Windows-ME.  It would appear to me that a lack of defensive coding, perhaps while reading or expanding a buffer full of data, causes unexpected inputs to crash the player.  I’d let this ride and just switch to ogg/vorbis format (which appears to work without problems), except at some point in the future I’ll probably copy an MP3 from another source onto the player and crash it again.

1 Like
4

All of the files you’ve posted are actually encoded with LAME, so while you are apparently using ffmpeg to call lame, I don’t think ffmpeg is really relevant here. The file sizes are different because the bitrate is set different (64 kbps vs. 192 kbps). All of the files you’ve posted look fine to me, so I don’t think there is anything special about them.

5

I am getting precisely this. I have used avconv, which calls lame, to convert flac/alac files to mp3

and have had the SanDisk crash.

I thought it was a corrupt memory card at first, and then started looking through the mp3

data fields.

I now realise why, but do not know how to fix this.

I did put these on at VBR 0. Maybe the sandisk clip cannot handle variable bit rates.

I will try a constant bit rate and get back to this thread.

Robin

6

Nope just put 192kbps constant on it and it still crashes the sandisk, but plays fine in linux.

So its not refusing a VBR.

Wonder if lame does something it can’t cope with.

7

I would check the tags. Weirdly formatted tags are notorious for crashing mp3 file parsers.

1 Like
8

Ah really? I just imported the m4a files into audacity, and wrote them out as 320 kbps mp3s

and they are playing fine. Maybe the script I wrote did not deal with the tags from the apple format properly.

Be nice to know what was really wrong though.

Here is the script I wrote, if anyone knows how to parse and sort out the tags

I’ll try it again and see if it works, meanwhile, enjoying

set the controls for the heart of the sun on my clip…

$ cat m4a\_to\_mp3.sh #!/bin/bash
# converts ALAC M4A Apple nonsense files to mp3 and converts spaces and tabs # to underscores in the file names.
SAVEIFS=$IFS IFS=$(echo -en "\n\b") for f in \*.m4a do echo " dollar f is " $f u=`echo $f | sed 's/[]/_/g'` echo u is $u remove all those stupid spaces in filenames cp $f $u t=`echo $u | sed 's/m4a$/mp3/'` ls -l \'$u\' echo dollar u: $u becomes dollar t: $t echo "PROCESSING: " avconv -i \'$f\' -f mp3 $t #avconv -i $u -qscale:a 0 -f mp3 output.mp3 avconv -i $u -f mp3 output.mp3 echo -------------------------- CONVERTED $f mv output.mp3 $t rm -rf $u done IFS=$SAVEIFS 2014-01-23\_12:04 ~/scripts