n10v / id3v2

🎵 ID3 decoding and encoding library for Go
https://pkg.go.dev/github.com/bogem/id3v2/v2
MIT License
334 stars 50 forks source link

Feature request: Add support for .m4a files (MPEG-4 container format) #82

Open GwynethLlewelyn opened 1 year ago

GwynethLlewelyn commented 1 year ago

Hi there,

After several hours of scratching my head about why none of the tags I was writing to a file were being saved, I finally managed to understand what was wrong: I was trying to add ID3v2 tags to a MPEG-4 container, not a MP3!

Reading your code, I believe you might consider slightly changing the code of parse(), which currently will return an empty tag (i.e. set to nil) if the file does not contain the magic word ID3 at the beginning. Your parseHeader() correctly returns a errNoTag to parse(), but that error is silently discarded when passed upstream. It might make some sense in some scenarios, but, in my case, I would rather prefer to get a ErrNoTag (i.e. a global error that can be checked by the code calling your library) instead of an all-ok, here's-your-empty-Tag-to-play-with approach. Notably, at this moment, I cannot use your library to figure out if it did open the file I told it to open, and that this file remains open for writing at a later stage.

This means that there is no clue about attempting to read or write the 'wrong' container format.

Anyway, it would be nice if you could add support for writing tags to .m4a files as well. This, of course, requires a lot of work, but... you might really not need to do much, except for including the go-mp4tag library. This will essentially write out iTunes-compatible tags to a MPEG-4 container (but there is flexibility to add your own), as well as the album cover in a 'proper' format. While this particular library is essentially write-only, @Sorrow446 is currently experimenting with a read & write version. Both versions, of course, rely heavily on the popular abema/go-mp4 library — which is terribly complex but does everything.

It would be nice to have a combination of both in a single library 😸 — which would make it work just like things like ffmpeg, which doesn't really care about what the destination format is: it will just use the appropriate tagging system, transparently to the user.

Thanks! :)