Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: same mp3 files behave differently in iPhone app (Read 8140 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

same mp3 files behave differently in iPhone app

I have 2 mp3 files that are nearly identical. The first file refused to stream down and play in my iPhone app that I am developing:

http://www.zerogravpro.com/temp/bad.mp3  (you'll find you can play this just fine in your browser, or download it and it plays fine)

This is 100% replicatable; it's not sporadic at all. The actual behavior is that the file begins to play in the iphone mediaPlayer for just a split second, then stops with some kind of "unknown" error. So then I took that file, opened it in audacity, removed the first split-second of silence from the beginning of the clip, and re-generated the mp3:

http://www.zerogravpro.com/temp/good.mp3

And this one works perfectly in the iphone app! 100% success each and every time. I have many mp3 files that are similar to bad.mp3 in that they play fine in any audio device, but error out when streaming/playing in iphone's media player. Audacity fixed it somehow and I need to know how/why, so that I can automate the fix in my hundreds of other mp3 files. I'd love to not have to open hundreds of files in Audacity and re-save. There must be some way to automate these fixes. How did Audacity fix the file? What did it do? I can only think of 2 possibilities:

- The existence of a split second of silence at the beginning of the clip chokes iphone
- Audacity fixes something non-obvious in the mp3

Experts: Any idea what the difference is between these 2 files, and how I could automatically turn "bad" mp3s into good ones, from some command-line tool or something? Thanks all.

same mp3 files behave differently in iPhone app

Reply #1
you could try installing foobar2000 and then adding the files to a playlist. now highlight them all>right click>fix vbr header.

TRY THIS ON COPIES OF FILES FIRST, NOT THE ORIGINALS.

http://www.foobar2000.org/

same mp3 files behave differently in iPhone app

Reply #2
I'd hardly call 128kbps and 24kbps "nearly identical".

Unless Apple decided to refuse accepting such a low bitrate, you could indeed try and use foobar2000, but not for "fixing the VBR header", as marc2003 suggested, because you are are dealing with CBR encodes.

Instead, you could try and right-click your mp3 file in foobar2000 -> utilities -> rebuild mp3 stream

HTH

same mp3 files behave differently in iPhone app

Reply #3
Btw. opening your mp3 in audacity, effectively decompresses the audiodata.
Exporting it afterwards as mp3 again, results in a entirely new mp3 file that appears to be compliant with your app(le).

Looking deeper into your two files reveals three flags that are not present in your "bad" file:

<ENC_DELAY> : 576
<ENC_PADDING> : 743
<MP3_ACCURATE_LENGTH> : yes

Maybe those two missing ENC_* flags cause your problem ?

same mp3 files behave differently in iPhone app

Reply #4
Btw. opening your mp3 in audacity, effectively decompresses the audiodata.
Exporting it afterwards as mp3 again, results in a entirely new mp3 file that appears to be compliant with your app(le).

Looking deeper into your two files reveals three flags that are not present in your "bad" file:

<ENC_DELAY> : 576
<ENC_PADDING> : 743
<MP3_ACCURATE_LENGTH> : yes

Maybe those two missing ENC_* flags cause your problem ?


So is there some automated way to add those missing flags to a ton of files, in cases where they're missing?

same mp3 files behave differently in iPhone app

Reply #5
Audacity didn't fix your file, it created a completely new file from scratch. No part of your second file is the same as the first file.

Those three fields Maggi mentioned are added by the lame encoder, but are not required for an mp3 to be valid. Adding them isn't going to solve your problem.

Did you try "rebuild mp3 stream"?

If you can't find another solution, you can batch re-encode as many mp3 files as you want in fb2k (or several other programs) with a couple of mouse clicks - no need to do them one-by-one in audacity.

Cheers,
David.

same mp3 files behave differently in iPhone app

Reply #6
First I want to really thank 2Bdecided, Maggi, and marc2003 for jumping in and trying to help me. Much appreciated.

The suggested solutions have not worked. Specifics:

- I took a different mp3 file that choked in iphone app but works fine in web, desktop, etc.
- I opened it in foobar2000 v1.3.4.
- I did Utilities->Rebuild MP3 stream
- I tried to play it in the iphone app - no dice, same problem: plays the first split second and quits with an error
- I went back and did Utilities->Fix VBR MP3 header - again made no difference
- I opened this same file in Audacity and re-generated the mp3. Now it works perfectly in iphone app

It seems that Audacity doesn't have a cmd-line or batch tool of any kind, so this still isn't a good solution.

Here is the mp3 after running the 2 utilities in fobar2000:
http://www.zerogravpro.com/temp/foobar2000.mp3

And here is the same mp3 after regenerating it in Audacity:
http://www.zerogravpro.com/temp/audacity.mp3

Can anyone see a difference between these 2 files that could make the difference, and is there a batch or cmd-line tool for the fix? Important: the iphone app is attempting to STREAM down the file, not download-then-play.





same mp3 files behave differently in iPhone app

Reply #11
julf: Any idea what command I would invoke on SoX?


Have we established if re-encoding the mp3 is enough, or if you still need to remove a short segment at the beginning of the file?

same mp3 files behave differently in iPhone app

Reply #12
If you're indeed accepting to transcode all problematic files, you could easily use foobar2000 for that.

Just make a playlist with all those files, right-click the playlist -> contents -> convert -> choose/define output format (LAME MP3) and destination -> hit convert

same mp3 files behave differently in iPhone app

Reply #13
julf: Any idea what command I would invoke on SoX?


Have we established if re-encoding the mp3 is enough, or if you still need to remove a short segment at the beginning of the file?


Sorry, I should have mentioned. Removing blank audio at the beginning seems to be irrelevant. The only guaranteed fix I have found is opening in Audacity and exporting back to mp3.

same mp3 files behave differently in iPhone app

Reply #14
Sorry, I should have mentioned. Removing blank audio at the beginning seems to be irrelevant. The only guaranteed fix I have found is opening in Audacity and exporting back to mp3.


In that case, see the answer from Maggi above anout using foobar2000 for batch transcoding.

same mp3 files behave differently in iPhone app

Reply #15
If you're indeed accepting to transcode all problematic files, you could easily use foobar2000 for that.

Just make a playlist with all those files, right-click the playlist -> contents -> convert -> choose/define output format (LAME MP3) and destination -> hit convert


Maggi: I achieved some success with your approach, but only about 80% of files were fixed. The remaining 20% could only be fixed through the manual Audacity export.

 

same mp3 files behave differently in iPhone app

Reply #16
Maggi: I achieved some success with your approach, but only about 80% of files were fixed. The remaining 20% could only be fixed through the manual Audacity export.


It must be something else in that case. Converting from MP3 to MP3 in fb2k will produce an entirely new file. It implies something else is at work, more than likely to do with tags? Try using mp3tag to remove all tags from the files and see what happens.