Archived from the Transloadit support forum. Originally posted on June 24, 2011; details may be outdated, see our docs for current behavior. Original thread
Hi,
we have a number of audio uploads failing with the message
Invalid data found when processing input
The failing tracks all seem to have artwork embedded in the meta data of the file and I’m wondering if this could be the invalid data? I’ve tried using the strip: true parameter in my template but it appears to have no effect on the result. Is there anything else I can do in my template to get these files working?
I’ve examined your file and ffmpeg indeed doesn’t handle it too smoothly
[mp3 @ 0x92a5420]max_analyze_duration reached
This is due to the fact that it will scan ~2MB of the beginning of the file in order to determine the filetype. If you store binary date inside ID3 tags, that space is used up by non-mp3 data and so ffmpeg is unable to determine the filetype.
I’ve already discussed this with ffmpeg core developers but a fix is not underway shortly.
A workaround would be to empty the ID3 tags before feeding the file to mp3, but I don’t think strip: true will do that, am I right (other) Felix?
strip: true caused all our uploads to fail when I tried it on our staging box so I don’t think it’s the answer. But if we could somehow strip our files of all the ID3 tags that would be fine as we re-add them later in our delivery process.
I don’t think we support a strip option for the audio bot. Afaik we only support this for image resizing and it’s done using image magick, so this won’t help here.
However, Kevin: Can you investigate to see if ffmpeg might have a similar option, or something to increase the max_analyze_duration? I mean we can set this duration really high, I don’t think it would cause us much problems other than that ffmpeg would try harder to work with files that have these kinds of meta data.
Ok, we have an idea: We will try to use one of our meta data tools (exiftool) to strip the meta information from mp3 files if we see this type of error. Would that work for you?
sorry, it’s not completed yet. But I’m almost done with releasing the new audio bot which will fix it, I just got distracted with other stuff coming in a bit.
I have some time to work on this today, but the file originally referenced in this discussion is no longer around. Could you give me a new url / assembly id to look at?
I just deployed the fix. Basically ffmpeg sucks at detecting that an mp3 is an mp3 if it has a big image in the id3v2 tags. What we are doing now is to explicitly tell ffmpeg when the input is an mp3 file, which skips its internal detection mechanism, fixing this bug.
