#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 18 months ago.
BigMetadataExample.mp3 (802.1 KB) - added by AGMS 18 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)

Changed 18 months ago by dsuden

Attachment: screenshot2.png added

comment:1 Changed 18 months ago by dsuden

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

comment:2 Changed 18 months ago by luroh

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

comment:3 in reply to:  2 ; Changed 18 months ago by 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, 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 18 months ago by AGMS (previous) (diff)

comment:4 in reply to:  3 Changed 18 months ago by 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.

comment:5 Changed 18 months ago by vidrep

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

comment:6 Changed 18 months ago by 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.

comment:7 Changed 18 months ago by 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.

comment:8 Changed 18 months ago by 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.

comment:9 Changed 18 months ago by 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?

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

Changed 18 months ago by AGMS

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 Changed 18 months ago by 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.

comment:11 Changed 18 months ago by 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.

comment:12 Changed 17 months ago by 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.

comment:13 Changed 17 months ago by 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.

comment:14 Changed 17 months ago by 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.

comment:15 Changed 17 months ago by 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.

comment:16 in reply to:  15 Changed 17 months ago by 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...

comment:17 Changed 16 months ago by 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.

comment:18 Changed 13 months ago by waddlesplash

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

comment:19 Changed 13 months ago by waddlesplash

Resolution: fixed
Status: newclosed

Fixed in hrev52057.

comment:20 Changed 13 months ago by AGMS

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 Changed 13 months ago by vidrep

It plays fine for me on hrev52065 x86_gcc2h.

comment:22 Changed 13 months ago by AGMS

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

comment:23 Changed 13 months ago by waddlesplash

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