Cannot CopyMetadataTo

[Agagamand]

The problem

When I try to save an error appears.

System.NullReferenceException: "Object reference not set to an instance of an object."

Not all tags are transferred.

Files for test: https://workupload.com/file/njuDN4pNrnJ

Environment

• ATL version (or git revision) that exhibits the issue: 5.13
• OS/version used to run ATL: Windows 11

Code To Reproduce Issue [ Good To Have ]

Track inputTrack = new("06 - Україно.tak");
Track outputTrack = new("06 - Україно.m4a");
inputTrack.CopyMetadataTo(outputTrack);
outputTrack.Save();

[Zeugma440]

Thanks for your report! It's been fixed for next release.

[Zeugma440]

The fix is available in today's v5.14~

Please close the issue if you confirm it.

[Agagamand]

If I transfer tags to m4a, then mp3tag.exe does not see AdditionalFields and cover art. If I transfer tags to mp3, then the mp3tag.exe does not see the cover and adds several additional ALBUMCOMMENT tags. Screenshots: https://workupload.com/archive/wVDFeWtEZM mp3: https://workupload.com/file/pfKdEBaYMqZ

[Zeugma440]

I've fixed the issue for cover art. Sorry about that.

Here's the detailed rundown on your report :

If I transfer tags to mp3, then the mp3tag.exe does not see the cover...

That has been fixed for next release.

...and adds several additional ALBUMCOMMENT tags.

That one's very interesting. When opening the raw target MP3 file using an hex editor, one can see ATL has properly copied the value from the original file into one single field.

When opening the MP3 file with MP3tag, one can also observe that the multiple lines that are displayed are all chunks of the original value, separated where the ; character is present.

=> I think that's an MP3tag display behaviour when viewing ID3v2 tags, not a problem from ATL.

If I transfer tags to m4a, then mp3tag.exe does not see AdditionalFields...

There are two issues at work here :

• PUBLISHER : That field is standard and shouldn't even appear in AdditionalFields. I completely forgot to map that APEtag field to the ATL standard fields. That's now fixed.

• ALBUMCATALOG, ALBUMCOMMENT, COUNTRY, DISTRIBUTED : These ones are custom fields that do not follow any standard APEtag naming. When copying them to an MP3 file, ATL uses the ID3v2 standard, which supports custom fields. However, the M4A structure has a limited set of metadata and only support custom fields that are provided with a namespace. Hence these values being ignored.

There's a possible workaround that is to automatically give these values a namespace (e.g. atl:ALBUMCATALOG), to make them appear among saved metadata. Would you be OK with that solution?

...and cover art.

That has been fixed for next release.

[Agagamand]

There's a possible workaround that is to automatically give these values a namespace (e.g. atl:ALBUMCATALOG), to make them appear among saved metadata. Would you be OK with that solution?

How does mp3tag.exe solve this problem?

[Zeugma440]

They do what I suggested, and use com.apple.iTunes as a namespace. Is that fine to you?

[Agagamand]

use com.apple.iTunes as a namespace. Is that fine to you?

Yes. I want maximum compatibility with mp3tag.exe. This namespace uses the same: https://github.com/Moonbase59/loudgain

[Agagamand]

That one's very interesting. When opening the raw target MP3 file using an hex editor, one can see ATL has properly copied the value from the original file into one single field.

How about the LYRICS tag? It CANNOT be a one-liner. And this field is not transferred using CopyMetadataTo I checked on both mp3 and m4a. Also a problem with the mp3tag.exe?.. But if you add a field to the mp3tag.exe then foobar2000 sees this field correctly.

[Zeugma440]

How about the LYRICS tag?

They should be fine. At least my tests don't show anything unusual.

Could you send me a file with lyrics that you cannot transfer?

[Agagamand]

I added a LYRICS tag to the file "06 - Україно.tak" https://workupload.com/file/M8rdeHhn939

[Zeugma440]

Thank you. APEtag had a dumb issue when reading lyrics. It's fixed now; thanks for your patience.

I'm doing a release today as much has been done since the start of our discussion.

[Zeugma440]

All fixes are available on today's v5.15 ✅

Please close the issue if it works on your side. Don't hesitate to open new issues if you find anything else.

[Agagamand]

I think that it is not worth converting the value of the YEAR field from 2003 to 2003-01-01. It's better not to change 2003.

[Zeugma440]

You're right. That has been adjusted for next release.

[Zeugma440]

Fix is available on today's v5.16

Please close the issue if it works on your side~