Unable to remove movement tag with --meta-remove-property

[scapix]

--meta-remove-property=movement does not remove movement property from tagged file(s)

[sandreas]

Thx for reporting, i'll take a look.

[cybergurke]

I have the same issue with recording-date.

tone tag file.m4b --meta-remove-property recording-date
Error: recording-date is not a valid value for MetadataProperty.

[sandreas]

@cybergurke @scapix
tone 0.1.6 is out. Since it is the first release after a long time, this issue may have been fixed with the new atldotnet release. I would love to get feedback, please backup your files.

[vincentkoevoets]

I'm on version 0.1.8 and just ran into this problem. I try to clean an m4b file of all tags first, before setting only the tags that I want. So now I have only the title tag left, and the part and movement tags. Then I run

tone tag --taggers="remove" --meta-remove-property=part test.m4b

And output shows that part as well as movement tags are set to null. After that, a dump shows the file still has part and movement tags with their previous values. So either I'm trying to do something the program doesn't expect, or something else is wrong.
I also have mp3tag on a Windows pc, to check which tags are still present. Strangely mp3tag shows no tags at all after removing with tone.

[sandreas]

@vincentkoevoets Thanks for reporting. Yeah part is one of tone's meta fields, that might be broken. I'll check this again.

Regarding mp3tag, this might be a really serious problem, because mp3tag is a reference tool - hopefully tone does not break anything. I'm going to look for this as soon as possible.

[vincentkoevoets]

Yes that's how I also use mp3tag. As far as I can tell tone does not break anything. I did some more testing. Some things that stood out:

• When using --meta-movement="17", --meta-part is also set to the same number. This also happens when using --meta-remove-property for one of these two tags (but, removing doesn't work as we know. But the output shows both these values set to null).
• Once one of these is set (and thus both are set, effectively), they cannot be removed anymore.
• I was able to start over by wiping all tags with exiftool, and was able to confirm something else: after using exiftool, the dump shows only the title tag, with the name of the file as title value. Then after using one or both of --meta-movement= or --meta-part, the dump shows both these tags with the correct value. But at this point, mp3tag does still only show the title tag.

Those were my findings so far. I'm not an expert, but if there is anything I can do, just say the word. Tone seems like a very promising and versatile application!

[sandreas]

@vincentkoevoets

Thanks for your detailed report. I think I might have found the problem, movement is a specified property (for ID3 and M4A), which is an integer. This results in a problem - how would you store part 2.5 or part 2a, it's not possible. Therefore I created PART as a meta-property, that does not exist in the specification. Everytime you try to specify a part, it checks for an integer, and if it is not an integer, it stores the value "as good as possible" either only in part or in part AND movement.

The problem is that it has to create an additional property (which is not in the specification) and this can only be removed when handled correctly. There is an issue with that, I'll try to fix this asap.

[sandreas]

@vincentkoevoets
Update: I found the problem. A change in atldotnet combined with an issue in tone led to this problem. tone 0.1.9 will potentially fix this, but I have to do some tests to ensure the correct behaviour. There is much stuff to test and I don't want to run in regression bugs :-)

[sandreas]

@vincentkoevoets Awaiting fix of Zeugma440/atldotnet#285
This must be fixed before 0.1.9, otherwise I would release a bug.

[vincentkoevoets]

Hey @sandreas, so sorry for not responding anymore, I've been very busy. But now I see you've been busy too! I'm no expert but I think I can understand what you're describing. In fact I came here to suggest it might have had something to do with an update or change in atldotnet. Glad you found it, and that this problem is solved (or at least will be in future release). Thanks!