Certain MP3 files refuse to play, are not recognized

[dsuden]

Under newer versions of Haiku, some MP3 files won't play. Big problem for TuneTracker folks. Here's one such file.

​http://www.tunetrackersystems.com/files/TABLE%20TALK_42-JANUARY%2027TH%20SHOW%20LOVE%20STARTS%20HERE%20REPEAT.mp3

Note the files play fine under earlier versions of Haiku, and under BeOS. Has something happened in the media kit? Attached is grab showing the message that appears when the unsupported files are double-clicked.

[dsuden]

Just wondering if this is the old album art in the header foible?

[luroh]

Do you have an example of a Haiku version having problems? The file seems to play fine here on hrev51788 gcc2h.

[AGMS]

Replying to luroh:

The file seems to play fine here on hrev51788 gcc2h.

It doesn't quite work on that hrev. It starts playing fine, but... Try seeking to a different spot in the sound and it plays silence. Optionally may crash (or crash on exit).

I did some experiments, taking off the ID3v2 and v1 tags (using "id3v2" under Linux to delete the whole tag area or just elements of it). Works fine with no tags (can seek and it plays). Also works fine if I remove the 700KB album artwork tag, leaving just smaller ones (artist name etc).

[luroh]

Replying to Alexander G. M. Smith:

Try seeking to a different spot in the sound and it plays silence.

Confirmed. Crashes too as you describe.

[vidrep]

I see this on MP3 streams using BePodder as well. It's more prevalent on 64 bit.

[AGMS]

I wonder if it's a hard coded tag size limit (perhaps 512KB) where larger metadata overflows something.

Or perhaps the code doesn't properly read the ID3 4 byte tag size, since it's encoded with 7 bits of data per byte (high bit is 0 to avoid looking like an MP3 sync marker, which is 11 bits of all 1s). Then if the code treats the size as a normal 32 bit number, it could think the tag is bigger than it actually is.

Or it could be something else. Just guessing here.

[pulkomandy]

AFAIK we are not doing anything with the tags, and this is all handled by ffmpeg. I hope they get these things right?

First of all, did the changes in ffmpeg 3.4.1-4 help? Previous versions of ffmpeg 3.4.1 were very crashy for me and this one seems to be better so far.

[AGMS]

Running MediaPlayer from the command line yields a few more clues. When you try to seek in one of the bad files, you get these errors (the last one repeats while it plays silence):

[libmodplug @ 0x1870d480] Max file size reach (see -max_size), allocating 5242880B but demuxing is likely to fail due to incomplete buffer
BMediaTrack::FindKeyFrameForFrame: extractor seek failed: General system error
  seek to key frame backward: 12766950 -> 180224 (180224) - General system error
BMediaTrack::FindKeyFrameForFrame: extractor seek failed: General system error
  seek to key frame backward: 12767832 -> 180224 (180224) - General system error

and that does suggest a 512KB hard coded limit somewhere. I'll have to see where that -max_size comes from. I'd recommend upping it to 10 MB, just in case someone includes a 5MB photo in their metadata, or has years of daily Adobe Audition change logs embedded.

[pulkomandy]

"libmodplug" is used to play amiga MOD files. It is clueless about MP3. So bumping that limit is unlikely to be the right fix.

We should investigate why we end up feeding the data to libmodplug instead of the appropriate MP3 decoder in ffmpeg. The most likely reason is failure to detect the file/data MIME type. Because MOD files don't really have an header, the sniffing rule for them is quite tolerant and will sometimes mistakenly accept other data. However, it should have lower priority than other rules to avoid interferences.

We should review what happens when seeking, because sniffing should be done only once and using the data from the start of the file. So the ffmpeg plugin shouldn't change his mind about the file type when seeking.

The link in the ticket yields a 404 error for me. Is the file gone?

[AGMS]

MP3 audio file with 700KB of metadata, makes MediaPlayer malfunction (silence for a while or crashes) when you skip forwards or backwards (run MediaPlayer in a window to see the error messages).

[AGMS]

I made an example MP3 file, with the same metadata as the vanished original example, but much less sound (instead of multiple megabytes which would take up too much space here). MediaPlayer still has problems seeking in it, though it can often resync and resume playing after a second or two. Run MediaPlayer in a Terminal window to see the error messages. Even more messages if you build it with debugging enabled.

[AGMS]

After a bit of experimenting, I was able to build the system without libmodplug and MediaPlayer plays the files somewhat better. You can seek back and forth without crashing, except it thinks the file is too long (possibly by the length of the metadata) so seeking near the end makes it play silence.

By the way, the libmodplug has a built in default maximum file size of 5MB, yet seems to use 512KB. I wasn't able to find out where that lower limit was being set. So I just removed the whole thing.

I made the hacked up ffmpeg minus libmodplug using HaikuPorter and changes in ​https://github.com/agmsmith/haikuports/tree/FfmpegNoModPlug You can download the gcc2 build at ​http://web.ncf.ca/au829/BeOS/ffmpeg-0.10.16-2-x86_gcc2.hpkg if you want to try improving your hrev51700 or later system.

[AGMS]

A better work around for now is to remove the big metadata MP3 tags. Turns out you can use ffmpeg to do that. The magic command line is:

ffmpeg -i InputFile.mp3 -map 0:a -acodec copy -map_metadata 0 -id3v2_version 3 -write_id3v1 1 OutputFile.mp3

The -map 0:a only copies over the audio data (the album art shows up as a video stream), the metadata stuff copies over all the kinds ffmpeg knows (just the standard ones), coincidentally leaving behind the bad ones. The -acodec copy makes it copy the audio data, no recompression involved, so there's no loss in quality.

[dsuden]

Just wanted to add that this problem seems to be fairly recent. Since some customers have moved to newer Haiku builds from a previous one from about a year ago, they've started experiencing this with their files. Those same files worked fine under older Haiku versions.

[korli]

There is now a "ffmpeg_tools" package which provides ffplay. One can theoretically check that a file is correctly identified and played by ffmpeg.

[pulkomandy]

theoretically? I made the needed work to get ffplay working precisely for that purpose. And indeed at least for the videos I was experimenting with, it did play it correctly and even had a warning message hinting me to what the problem was in MediaPlayer.

So, do try ffplay to see if at least on the ffmpeg side, the file is sane.

[korli]

Replying to PulkoMandy:

theoretically? I made the needed work to get ffplay working precisely for that purpose. And

I didn't test it, you probably didn't test it on x86_64 also...

[vidrep]

I have a .mp3 that plays, but cannot seek. It will not resume play after moving the progress bar. If I use MediaConverter to create a .wav with raw encoding with that same file, then it works OK.

[waddlesplash]

Confirmed that ​https://github.com/haikuports/haikuports/pull/2758 fixes this issue for GCC2.

[waddlesplash]

Fixed in hrev52057.

[AGMS]

Still doesn't work, the example file attached to this bug report BigMetadataExample.mp3​ shows up with a duration of -6 seconds and doesn't play at all. At least it doesn't crash! Though if you run MediaPlayer from the command line, you'll see plenty of error messages.

[vidrep]

It plays fine for me on hrev52065 x86_gcc2h.

[AGMS]

Whoops, my bad, was a VirtualBox configuration error that had turned off all sound. So, yes, the bug is fixed.