[FFmpeg-devel] detecting MP3 content following ID3 tags over PROBE_BUF_MAX
Michael Niedermayer
michaelni at gmx.at
Mon Mar 19 20:37:55 CET 2012
Hi Ami
On Mon, Mar 19, 2012 at 11:42:18AM -0700, Ami Fischman wrote:
> >
> > Hi Michael,
>
> In a merge<http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=6faf0a21e18f314c48a886864145abe715be6572>
> you
> removed the effect of a
> patch<http://git.libav.org/?p=libav.git;a=commit;f=libavformat/utils.c;h=61856d06eb30955290911140e6745bad93a25323>
> by
> Alex Converse which encouraged identification as mp3 of files with leading
> ID3 tags that are so large as to prevent direct identification within the
> first PROBE_BUF_MAX bytes.
> Can you describe the reasons for the removal?
its a bit hard after half a year to remember exactly but it likely
didnt look like it was needed or looked incorrect to me.
and carls reply seems to confirm this ...
>
> This came up in the context of a chrome bug <http://crbug.com/110309> report
> with users complaining that certain MP3's encoded with large album artwork
> in ID3 tags fail to play in chrome.
> The same file plays fine in ffplay if it's named with an mp3 extension, but
> not otherwise (since probing fails).
>
> Although ID3 tags are not exclusive to MP3, it seems like a reasonable
> guess to make in the absence of higher-scoring probe matches given the
> distribution of ID3 tags in files in the wild, no?
yes, give me a moment ill make sure the files get detected as mp3
even with random extensions
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120319/b8013adb/attachment.asc>
More information about the ffmpeg-devel
mailing list