You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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! :)
The text was updated successfully, but these errors were encountered:
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 emptytag
(i.e. set tonil
) if the file does not contain the magic wordID3
at the beginning. YourparseHeader()
correctly returns aerrNoTag
toparse()
, 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 aErrNoTag
(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! :)
The text was updated successfully, but these errors were encountered: