monkey's audio (.ape) demuxer can't handle id3v2 tags (partial-fix patch)

[peter@…]

I have some .ape files that have id3v2 headers. mplayer doesn't even recognize them as Monkey's Audio files unless I say -lavfdopts format=ape.

Even with that, libavformat/ape.c doesn't know how to skip leading junk, such as id3v2 tags. I tried to fix it, and now mplayer segfaults after playing < 1 second of tagged .ape files. (It still works fine on the same .ape files with the tag stripped.) Anyway, I hope this helps someone get started on fixing mplayer's problems with id3v2 tagged .ape files. happy hacking.

Index: libavformat/ape.c
===================================================================
--- libavformat/ape.c (revision 11070)
+++ libavformat/ape.c (working copy)
@@ -279,9 +279,15 @@

int64_t pts;

/* TODO: Skip any leading junk such as id3v2 tags */

• ape->junklength = 0;

+ tag=get_le32(pb); skip junk
+/* This is a stupid and slow way to search for a 4 byte string,
+ * because I don't know how to use mplayer's buffer functions.
+ * TODO: get the on-disk byte representation in a string and search forwards for that in a buffer with e.g. GNU libc's memmem(). */
+ for(i=0 ; i<=1<<18 && tag != MKTAG('M', 'A', 'C', ' ') ; i++){
+ tag = (0xff & get_byte(pb))<<24 | tag>>8;
+ }
+ ape->junklength = i;

• tag = get_le32(pb);

if (tag != MKTAG('M', 'A', 'C', ' '))

return -1;

This is the first time I've ever hacked anything in mplayer that needed to deal with I/O...

[peter@…]

I was going to mention that libavformat/mp3.c has a bunch of functions for parsing and skipping id3v2 tags. Skipping arbitrary junk looking for magic 4 bytes might or might not be good. Maybe 256kB (1<<18) is too far, and could result in false positives. Although at this point mplayer only gets there with -lavdopts format=ape, so maybe just the auto-detecting ape code needs to be careful.

And my files have id3v2 tags with lengths like 4300B (some with non-multiple-of-4 lengths, though.)