#13981 closed bug (fixed)

Certain MP3 files refuse to play, are not recognized

Reported by: dsuden Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Audio & Video Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (2)

screenshot2.png (9.4 KB ) - added by dsuden 21 months ago.
BigMetadataExample.mp3 (802.1 KB ) - added by AGMS 21 months ago.
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).

Download all attachments as: .zip

Change History (25)

by dsuden, 21 months ago

Attachment: screenshot2.png added

comment:1 by dsuden, 21 months ago

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

comment:2 by luroh, 21 months ago

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

in reply to:  2 ; comment:3 by AGMS, 21 months ago

Replying to luroh:

The file seems to play fine here on hrev51788 gcc2h.

It doesn't quite work on that hrev. It starts playing, 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).

Last edited 21 months ago by AGMS (previous) (diff)

in reply to:  3 comment:4 by luroh, 21 months ago

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.

comment:5 by vidrep, 21 months ago

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

comment:6 by AGMS, 21 months ago

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.

comment:7 by pulkomandy, 21 months ago

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.

comment:8 by AGMS, 21 months ago

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.

comment:9 by pulkomandy, 21 months ago

"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?

Last edited 21 months ago by pulkomandy (previous) (diff)

by AGMS, 21 months ago

Attachment: BigMetadataExample.mp3 added

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).

comment:10 by AGMS, 21 months ago

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.

comment:11 by AGMS, 21 months ago

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.

comment:12 by AGMS, 21 months ago

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.

comment:13 by dsuden, 20 months ago

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.

comment:14 by korli, 20 months ago

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

comment:15 by pulkomandy, 20 months ago

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.

in reply to:  15 comment:16 by korli, 20 months ago

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...

comment:17 by vidrep, 19 months ago

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.

comment:18 by waddlesplash, 16 months ago

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

comment:19 by waddlesplash, 16 months ago

Resolution: fixed
Status: newclosed

Fixed in hrev52057.

comment:20 by AGMS, 16 months ago

Resolution: fixed
Status: closedreopened

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.

comment:21 by vidrep, 16 months ago

It plays fine for me on hrev52065 x86_gcc2h.

comment:22 by AGMS, 16 months ago

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

comment:23 by waddlesplash, 16 months ago

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.