-
Improvement
-
Resolution: Unresolved
-
Normal
-
None
-
2.6.3
-
None
Currently, Picard writes Conductor to ----:com.apple.iTunes:CONDUCTOR in m4a/mp4 files. According to PICARD-481, there is a dedicated atom for conductor, ©con. For example, ©con is used by foobar2000 and mp3tag. However, Picard cannot read or write ©con at all. This leads to interoperability issues.
If someone takes a Picard-written file with a CONDUCTOR value and re-saves the file in either foobar2000 or mp3tag, then those software move CONDUCTOR to ©con. If the file is given to Picard again, then Picard can't see ©con. If Picard tries to save the file against the release again, then Picard creates a new CONDUCTOR field. If the file is given to either foobar2000 or mp3tag, then both software will see 2 "CONDUCTOR" fields (one is ©con and the other is ----:com.apple.iTunes:CONDUCTOR).
Since Picard scripting cannot be used to fix this kind of metadata error, a user would have to tell Picard to move the field like this:
$set(conductor picard,$join(%conductor%,; )) $unset(conductor)
(Then in third-party scripting, "conductor picard" can be deleted if it's equivalent to ©con.)