MP3Tag does not properly strip chapters

Bug Reports No Bugs
1

After doing some extensive testing with the author of ATL we have discovered MP3Tag is not properly removing chapter data when doing strip chapters

Steps to reproduce

  1. Get an MP4/M4A/M4B file containing MP4 chapters ("chap" atom; not to confuse with Nero chapters defined with a "chpl" atom)
    e.g. https://auphonic.com/blog/2013/07/03/chapter-marks-and-enhanced-podcasts/

  2. Note the presence of

  • a "chap" atom inside the audio track's "tref" atom ;
  • at least one dedicated text track describing chapters ;
  • text data containing chapters titles, written inside one of the "mdat" atoms

NB : the file linked as an example has two text tracks describing respectively chapter titles and chapter URLs

  1. Use "Strip MP4 chapters" feature of MP3Tag

Expected behaviour

After stripping :

  • The "chap" atom of the audio track are removed ;
  • The chapter-related text tracks are removed ;
  • The text data containing chapter titles are removed.

Actual behaviour

After stripping :

  • The "chap" atom of the audio track disappears [OK; as expected]
  • The chapter-related text tracks are still present [KO]
  • The text data containing chapter titles is still present [KO]
2

I'm not quite sure if I understand correctly, but I think removing the text tracks completely would not be indented behavior.

As I see it, the text tracks are only semantically linked to represent chapter information, but nothing prevents another file to have a text track containing, e.g., subtitles.

3

What? I'm very confused by your statement. Maybe KO was confusing, it was the researchers way of saying bad result, knock out. The research was done on chapter addition and removal (stripping via mp3tag) it is not about subtitles (in audiobooks or music??) or lyrics. When removing chapters you need to remove all the mentioned data. None of that data is used by other features. This is specifically data under the chap atom. This has been thoroughly researched and tested. If you want to really dig in and see may I suggest removing the chapter data via ffmpeg and looking at the difference? The following will strip the Nero chapters and leave QuickTime chapters.

ffmpeg -i test.m4b -codec copy -map 0:0 -movflags disable_chpl output.m4b

4

What you did not mention is, that by providing -map 0:0 it only copies the audio stream at #0:0 and omits the others you're referring to (i.e., #0:1 tx3g aka "Chapter titles", #0:2 tx3g aka "Chapter URLs" and #0:3 mjpeg aka "Chapter Images"). It would also remove any video track if the file in question would be a video.

If this is what you need, then please use ffmpeg or the DLL you're referring to. As I've said, I'm fine with removing chap and chpl but not arbitrary tracks that may contain semantic references to chapter descriptions.

5

So what i'm hearing is you are trying to be more than an audio tagger? I was not aware you were also shooting for being a video tagger? My example was based on this being an audio only file of course but even then as I've tried to describe you specifically call this process strip chapters but you are leaving remnants behind? What is the reasoning for this? You say and I quote

As I've said, I'm fine with removing chap and chpl but not arbitrary tracks that may contain semantic references to chapter descriptions.

Isn't that the whole point of stripping chapters? To remove all that chapter information? That would include chapter descriptions. If there is no chapter what is the point of leaving a chapter description behind? To describe a nonexistent chapter?

Anyway this is much less of a issue for me than my other post. This one at least has a workaround. The other bug doesn't other than not using mp3tag or dealing with bad/rewritten chapters.

6

Just to be sure that I'm not missing something that you're aiming at:

You're suggesting that besides removing the chap and chpl atoms, strip chapters should also remove any streams that might be related to chapters.

I totally understand that you know that those tracks are describing the chapters (— in fact, I know this too from a human-looking-at-the-data perspective). However, since there is no container-level way of describing the relation between a track (or another metadata field like Lyrics or Description in the example file) and the concept of chapters, the last resort to identify such information would be a basic text-search for "chapter" or the like.

It's more of a side-effect of supporting container formats that can also hold video data. Same for Matroska.

7

I wish I could provide more detail here. I am not as familiar with the container format as I am sure you are. I am providing information to the best of my ability and how it was explained to me by the author of a DLL that writes chapter, lyrics, and tagging data that I have been helping with debugging chapter data. During this testing we used your program to strip the chapter data. During this process it was discovered some remnants were left behind when doing strip chapters that made it impossible to write new chapter data. At least not without a bunch of extra work to check for and clean up this data first. This is detailed in the original post word for word by provided him to me for posting. The feeling was rather than work around a "bug" to see if that bug can be resolved.

8

OK, thanks for the clarification. Maybe you can direct him to this post and if there is anything I'm missing, I would be great if you or he can point it out.

Thanks for the time you've put into this.

1 Like