search

n10v / id3v2

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

First implementation of chapter TOC #72

Open crra opened 2 years ago

crra commented 2 years ago

Hello Albert,

it seams like that some mp3 players need chapter TOCs in addition to chapter frames to function properly. I've introduced AddChapterTocFrame according to https://id3.org/id3v2-chapters-1.0. I kept the spirit of a 'low-level' API without renaming the boolean values in reverse to support default values (values must be explicitly set). The fields are also named according to the specification to avoid confusion.

crra commented 2 years ago

Hello @bogem,

did you find the chance to look at the pull request? If it's not to your liking, please help me to improve it. I want to get rid of my fork.

n10v commented 2 years ago

Hi @crra, thanks for your PR! It's great addition. I need some time to review the PR :)

crra commented 2 years ago

Sure, take your time. You can check the live application of the chapters TOCs with mp3binder. The chapters are enabled by default.

crra commented 2 years ago

Hello @bogem,

How do you read?

[...] followed by a sequence of optional frames that are embedded within the "CTOC" frame and which describe this element of the table of contents (e.g. a "TIT2" frame representing the name of the element) or provide related material such as URLs and images. These sub-frames are contained within the bounds of the "CTOC" frame as signalled by the size field in the "CTOC" frame header.

Does this mean any frame can be embedded? So it's like a new container for any id3v2 tags listed in common_ids.go? Even if they don't make sense like UFID? What do you think?

n10v commented 2 years ago

Hey @crra, sorry for not answering for a long time, had a lot of stuff to do.

That's good point actually, but it's so confusing (as a lot of places in id3v2 spec). When I read this, I also have the same understanding as you because of the sentence such as URLs and images. It seems that it should be a part of CTOC Descriptive Data and not only the text frame can be stored there. The Figure 2 only shows an example with TIT2 frame as descriptive data, but AFAIU everything can be there. And I have the same understanding as you that it's basically a new container for any id3v2 tags.

IMO it's a rare edge case that will require a lot of work and code to implement. IMO for now we can skip the whole descriptive data