Mp3tag showing “wrong” metadata on M4B files

[bengalih]

I have been a longtime (if not consistent) Mp3Tag user and give kudos and thanks.

So, first off I have put “wrong” in quotes because perhaps this is by design and I don’t fully understand. It could be that every single other program and coding library is wrong, and MP3Tag is right….I don’t know, but I want to understand what is happening in hopes of finding a solution.

In trying to script some metadata compares and copies with M4B files I have found some strange issues I don’t understand. If I clear all the tags out with MP3Tag and then just set the album name (Title), we see it gets updated here:

FFProbe output:

TAG:major_brand=isom
TAG:minor_version=512
TAG:compatible_brands=isomiso2mp41
TAG:creation_time=2019-06-05T05:17:04.000000Z
TAG:encoder=Lavf59.27.100
TAG:title=This is the title from Mp3tag

or

Atomic Parsley Output:

Atom "©too" contains: Lavf59.27.100
Atom "©nam" contains: Set from MP3Tag

This is all good…right now we have consistency with what I set in Mp3Tag and what external tags show. However, if I use another tool to set these values (for instance just using the details view in Windows Explorer), I see this for output:

FFProbe output:

TAG:major_brand=isom
TAG:minor_version=512
TAG:compatible_brands=isomiso2mp41
TAG:creation_time=2019-06-05T05:17:04.000000Z
TAG:encoder=Lavf59.27.100
TAG:title=Set from Explorer Details

or

Atomic Parsley Output:

Atom "©too" contains: Lavf59.27.100
Atom "©nam" contains: Set from Explorer Details

In fact every other tool (from Explorer, ffmpeg, mutagen (python), AtomicParsley, Picard, etc) will see this new “Set from Explorer” name, but MP3Tag will not. This is confusing to me because it seems like MP3Tag and these other tools are storing it in the "©nam" Atom when they set it, but I don’t understand why MP3 tag is refusing to recognize the value when set elsewhere and why not a single other tool or method I can find will show the value that MP3Tag is showing.

If I wasn’t such a long term MP3Tag user and not wanting to abandon it completely, I might just dismiss it as the only “broken” one out of the lot. However, I suspect it knows something I don’t and want to understand.

Can anyone explain this?

[MotleyG]

@bengalih

In fact every other tool (from Explorer, ffmpeg, mutagen (python), AtomicParsley, Picard, etc) will see this new “Set from Explorer” name, but MP3Tag will not

Where are you looking to “see” this data? If you are using the library feature and make tag edits outside of mp3tag you first have to force a refresh of the metadata. Select the file(s) you want to refresh and select Files>Read tag or Ctrl+T. Then open the Extended tags window with View>Extended tags or Alt+T. Post a screenshot here as this will display what mp3tag can really see.

[bengalih]

I am looking at the Tag Panel (left side) when the file is selected, and also in the Extended tags by right-clicking and choosing Extended Tags.

I am literally closing and re-opening MP3Tag in between every attempt at changing data, so there is no issue with refreshing tags.

[ohrenkino]

@bengalih

so there is no issue with refreshing tags.

There is if the modifying programs do not also update the “modified” date and MP3tag has the library switched on.

Did you press Ctrl-T to re-read the tags?

@bengalih

I am looking at the Tag Panel (left side)

The tag panel does not show properties like the tool (tag fields that start with an underscore) and the tag panel does not get automatically display more or fewer fields depending on the found fields in the files.

[MotleyG]

Alright since you didn’t post a screenshot or confirm if you had refreshed the offending file’s tags, let’s try this. Under File>Options>Library can you confirm if the checkbox beside “Library” is checked in your setup?

A picture is worth a thousand words. Especially for the Extended Tags information. The details there often shed the most amount of clues to help provide some guidance. Again I ask you to post a screenshot here to help take a look from a distance.

[bengalih]

I would need to refresh tags even if MP3Tag was closed entirely, and then reopened in between each attempt at checking?

But yes, I have verified that Ctrl-T does not change anything. I have put up a whole video for you guys to see exactly the issue I am seeing. I think you wil agree it isn’t an issue with reading cached info:

https://streamable.com/60bpa1

Thanks!

[bengalih]

I posted a video above, however I didn’t respond that I refreshed the tags with Ctrl+T, because I stated I was closing and reopening Mp3Tag completely. Does that not have the same effect or is there an actual cache? I’ve never seen an issue before where new tags were not loaded on a restart in 15+ years of using it?

[ohrenkino]

I cannot reproduce the issue.

I used an m4a file, set a new TITLE in MP3tag which was displayed accurately in Windows Explorer.

I then added a single character in the Windows Explorer Properties for TITLE, saved the change and pressed F5 in MP3tag which now also showed the added character.

I don’t have an m4b file, though.

[bengalih]

I’ve done some more testing and it appears you are right, M4A files are not affected.

It is only M4B files, and it appears only M4B files that actually have chapters.

[ohrenkino]

@bengalih

M4B files that actually have chapters.

See here on chapters in m4b files:

Chapters in .m4b

I'm editing the Chapters/Menus of several .m4b files. Here is my Problem: No matter what Program I use to add/delete Chapters, mp3tag will upon opening the file add the old chapters that were in the file to begin with. I tried stripping the file completely of all chapter information, Nero and Quicktime. I use mpeg4ip for this and confirmed it strips the chapter information with MediaInfo. In case MediaInfo was having a fluke I confirmed that they really are stripped with a bunch of players, no…

[bengalih]

So I’ve done a lot more testing. I don’t think the post you referenced is entirely relevant since that issue was around the chapter managment itself, not just changing a tag as simple as “title”. However three may be relvance between them. There definitely looks like complications due to the MB4 format. I hope @Florian can shed some light on this as he did with the other.

From what I can see, if I use MP4Box on one of these files to export and then re-import the chapter, the issue seems to resolve itself. I notice that when MP4Box writes, it creates a stream like this:

{
"index": 1,
"codec_name": "bin_data",
"codec_long_name": "binary data",
"codec_type": "data",
"codec_tag_string": "tx3g",
"codec_tag": "0x67337874",

Wheras, when FFmpeg creates it, it outputs this:

{
"index": 1,
"codec_name": "bin_data",
"codec_long_name": "binary data",
"codec_type": "data",
"codec_tag_string": "text",
"codec_tag": "0x74786574",

So, effectively it seems like the issue only occurs if the stream that embeds the chapters is of the “text” format AND have more than one chapter. If I use ffmpeg to create the file with only one chapter, it doesn’t seem to cause an issue, but the moment I add more than one the problem occurs.

If I export/import the chapters with MP4Box, it appears to convert them to “tx3g” format, which Mp3tag doesn’t seem to have an issue with. That being said, when I convert them, it doesn’t automatically fix the inconsistency between what Mp3tag shows and what Explorer shows, but if I save the tag once with Mp3tag, I can then seem to change it in either location and it is properly reflected.

I don’t know enough to say what is right/wrong here. All I know is that ffmpeg is heavily used to write chapter data to MB4 files using the ffmetadata1; format file. I also know that of all the tools I am using, Mp3tag seems to be the only one that is not recognizing changes to simple tags in this way.

Could it be a bug in that Mp3tag? The other crazy thing about this is that while Mp3tag apparently has no issues if my chapters are in the “tx3g” format from a tag writing standpoint, is that it does NOT honor those chapters as separate chapters when “List chapters….” is enabled. But it does do it for the TXT tags!!

And again, for what it is worth, other programs like ffmpeg, mediainfo, VLC, do recognize the chapters (for output or playback) with either option.

EDIT - To add on to this, I have done some more poking. It looks like if I use this when I do my ffmpeg conversion “movflags disable_chpl” that the issue is also resolved. That switch presumably doesn’t create Nero chapterization, only the QT.

That appears to be root issue: Mp3tag has issues with writing tags back to files with Nero chapters on MB4, but not to ones with just QT. But, alternatively, it cal only show “List chapters….” if the file has Nero tags.

ANOTHER EDIT - Found this:

MP4 files with chapters ignore all standard tags; create “ghost tags”

First of all: Thank you for your wonderful program that's served me so well all these years! Mp3tag currently creates Nero metadata for any MP4 file with chapters, but also writes to the standard metadata. This seems fine in theory, but apparently, it also means that Nero copies are created for every standard metadata tag that's set in that file, meaning that if the standard tags are changed with another program, Mp3tag cannot see the change, and the unchanged tags remain in the file a…

Apparently this is a realy issue that Mp3tag can’t deal with, which does make it unsuable in many respects on its own due to it’s reliance/forcing of this Nero data. I suppose that using it for MB4/MP4 chapterized files is simply not the use case for this application unless you don’t want to use any other program.

[MotleyG]

@bengalih

It is only M4B files, and it appears only M4B files that actually have chapters.

This is the first time you mentioned that you are using chapters. There is a separate option in mp3tag to enable support of chapters. Look at the setup under File>Options>Tags>Advanced and then make sure the checkbox for “List chapters as separate files” is enabled. This could be the difference you need to enable the visibility of these title tags.

[bengalih]

Well, most M4B files have chapters, that is kind of the point of using the format, so I didn’t think it was worth it to mention. I thought it was all M4B files since 99.9% of mine have chapters, but then I discovered one that didn’t have the issue and it was based on chapters.

And no, it has nothing to do with the “List chapter” option, I already discuss that above. This is clearly a deeper issue that has to do with how Mp3tag continues to force older Nero style tags. From the prior posts I referenced (after I started the thread), it seems others have brought this up before and it has either been ignored, or they have found a workaround re-writing tags with other programs, or it has been addressed as something that is not going to be fixed due to wanting to retain compatability with a 23 year old software (Foobar).

[Florian]

I've written a separate topic on the current state of iTunes/QuickTime and Nero metadata for MP4/M4A/M4B in Mp3tag, with the intention to answer all questions and shed some light into the issues described in this topic:

MP4/M4A/M4B: iTunes/QuickTime and Nero metadata

Mp3tag supports two tag formats for MP4/M4A/M4B: iTunes/QuickTime and Nero metadata. When writing metadata, Mp3tag tries to only use iTunes/QuickTime metadata if possible, but writes Nero metadata in the following circumstances: The file already contains Nero metadata. Mp3tag then updates both metadata formats with the updated contents. The file contains QuickTime chapters. Mp3tag can't edit QuickTime chapters at the moment — only reading and removing QuickTime chapters is supported. On w…

[bengalih]

Thanks Florian for clarifying the behavior. I believe that it is acting as you describe, I will update if I see otherwise (thought I did in some circumstances, but tested further and can’t recreate, so I think your scenarios given are correct). Would you mind updating that post with the reasons for the design? I’ve seen these issues scattered throughout the forum here, but not understood at all outside of it. It seems you did this solely for Foobar compatability? Would answer my questions and save future requests if that PSA included that info.

thanks again.

[Florian]

Mp3tag will create Nero chapters if it encounters QT chapters. It's because, while it can read QT chapters, it can't modify them — it's not a complete remuxer like ffmpeg is.

Previous versions of Mp3tag however (up until Mp3tag v3.31b I've just released), also copied artist, album, and other metadata to the Nero tags and prioritised those when reading.

This is now different, because it tries to create a minimal version of the metadata for the Nero tags (mostly title and track number). Every other "global" data is kept in QT tags and will be read and updated by Mp3tag and external tools.