Opened 8 years ago

Closed 7 years ago

#7848 closed bug (fixed)

MP3 not recognized by Media Kit

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

Description

The attached audio file cannot be played in Haiku. Details in comments. Didn't find previous occurences of this issue in media_server/media_kit/apps-MediaPlayer ..etc ticket categories, yet we (dsuden and I) have several problematic mp3s: Others that are not recognized.. And some that are, but the media-kit fails to parse their length, and reports them as "0 frames" (will file a distinct ticket if necessary).

Attachments (1)

Ernie Els- New Odds.mp3 (InitCheck() fails in mediakit) (959.2 KB) - added by ttcoder 8 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 8 years ago by ttcoder

Details:

  • the file plays correctly in BeOS and Windows.
  • the file yields this in Terminal with MediaPlayer: "Controller::SetTo: InitCheck failed"
  • the file yields this in Terminal with SoundPlayTT's call to BMediaFile::InitCheck(): "0x8000407f: No handler"

comment:2 Changed 8 years ago by stargatefan

does not play on the 3 windows machines I tried.

comment:3 Changed 8 years ago by ttcoder

I tried in BeOS R5 but not yet Windows.. Also in case it helps, dsuden has uploaded a whole lot of other mp3s that won't play in MediaPlayer, over here: http://www.fairharborradio.com/audiofiles/

comment:4 Changed 8 years ago by ttcoder

Just tried the above "Ernie hels" in an old Win XP Pro SP1 (after adding the "file extension" sillyness which windoze needs of course) and it worked without a problem, without an error message, without any glitch whatsoever, just fine.

When I have spare time I'll try to add tracing code to the mp3 decoder add-on.. Though wait, that code used to be in add-ons/media/plugins but is not there any more ?? Or has it been replaced by ffmpeg or something ? How do I debug this ?

comment:5 Changed 8 years ago by anevilyak

Looking at both the attached file and the ones on dsuden's server, one thing does stand out: they're all encoded at 48KHz rather than 44.1 or one of the other more typical sample rates. Could be related to that.

comment:6 Changed 8 years ago by dsuden

Entry below EDITED 4 Aug 2011 to fix lines that didn't wrap properly...

I did some testing of my audio files to see if we can bear out the 48 KHz theory. It seems to have some bearing, but doesn't seem to apply consistently. Here's what I found:

Here are the results of my tests of all my :30 PSAs...

Sampling Rate:

Among the PSA audio files that work:

44.1 Khz    84

48 Khz        9

Among the PSA audio files that don't work:

44.1 Khz    41

48 Khz       14

--

Bit Rate

Among the PSA audio files that work:

64 kbps      1

128 kbps    15

160 kbps    2

192 kbps    35

256 kbps    35

320 kbps    4

Among the PSA audio files that don't work:

64 kbps      1

128 kbps    0

160 kbps    0

192 kbps    0

256 kbps    50

320 kbps    5

My conclusion is that there seems to be a slight correlation between Haiku's failure to ID files and the higher bitrates and sampling rates, though it's not anything that's easily pinned down, where we can say, "all of the files of x bitrate and x sampling rate" fail.

The broader conclusion is that Haiku's handling of MP3 files seems "wobbly" due to some difficulties in reading some of them. In my experience, more than half of the MP3s work, but a worrying number of them fail to be ID'ed and/or played.

Last edited 8 years ago by dsuden (previous) (diff)

comment:7 Changed 8 years ago by dsuden

Someone in IRC told me he looked at the headers of some MP3 files that work and some from the link above that don't, and noticed a difference in the header files, or at least, he thought they looked different in diskprobe. Dunno if that's helpful, but it would suggest a possible are of investigation. As he said, "...could be the current mp3 decoder isn't flexible enough to handle these variances."

comment:8 Changed 7 years ago by korli

Could you please check this bug with hrev43846 or newer? I had such a case previously because the probe buffer size was only 2K.

comment:9 Changed 7 years ago by ttcoder

Thanks! Will do; though Dane will probably beat me to it since I cannot upgrade Haiku for the next 1 or 2 weeks.

comment:10 Changed 7 years ago by korli

Another option would be to only upgrade the ffmpeg media plugin on your installation. That's your call though.

comment:11 Changed 7 years ago by ttcoder

Got word from dsuden today -- "upgraded ffmpeg to hrev43888 as described by korli and now all mp3s are recognized".

Looks like this ticket can be closed!

Have another one about AIFF files too, since they are handled by ffmpeg too the upgrade could have an impact, will check if that other ticket can be closed too.

comment:12 Changed 7 years ago by korli

Resolution: fixed
Status: newclosed

Thanks for the feedback.

Note: See TracTickets for help on using tickets.