atldotnet icon indicating copy to clipboard operation
atldotnet copied to clipboard

Optimization - Don't write when there's no modified metadata

Open Zeugma440 opened this issue 3 years ago • 6 comments

Prevent modifying files on Track.Save, if the metadata has not changed

Zeugma440 avatar May 25 '22 14:05 Zeugma440

Cool to see that is regarded now. Maybe it would be nice to keep a possibility to force a save under specific circumstances.

mp4v2 has a tool mp4tag with a parameter --optimize, which does some black magic voodoo to optimize the structure of mp4 containers. I don't know, if this is a good idea, but maybe ForceSave or SaveOptimized is an option for Track.

sandreas avatar May 25 '22 18:05 sandreas

mp4v2 has a tool mp4tag with a parameter --optimize, which does some black magic voodoo to optimize the structure of mp4 containers. I don't know, if this is a good idea, but maybe ForceSave or SaveOptimized is an option for Track.

I agree with you about the need for a "force save" option, but I have no idea what kind of "black magic" that tool does to optimize files. Is there any spec or description about that ?

Zeugma440 avatar Jun 06 '22 14:06 Zeugma440

Thank you for taking a look.

Is there any spec or description about that ?

Yes, here. @enzo1982 took a huge effort create a documentation, see https://mp4v2.org

@item --optimize
optimize mp4 structure.
This will rewrite the entire mp4 file which, if needed, will clean up
any unused (free) sections, and re-order the atoms in a manner somewhat
consistent with the best-practices described in the ISO base media file
specification.

I think, that the optimization is not necessary until it is really requested. Maybe this would be good for files like #152 and should be called --repair. But for now I think this would be nice-to-have and can be ignored. I think atldotnet is awesome, but not a forensic tool responsible fix user errors or bogus files created by other software.

sandreas avatar Jun 06 '22 16:06 sandreas

I've been implementing that and just realized the client-side impacts are much more important than I thought.

Many "advanced" features of ATL are not triggered by the content of the metadata you're writing but by values you switch on and off using ATL.Settings.

Example 1 : Convert ID3v2.4 to ID3v2.3 Example 2 : Cap the number of Nero chapters to 255 to make them readable on VLC Example 3 : Save all chapters as QT chapters instead of Nero Chapters (the list goes on...)

All these features need to update the file even if metadata itself hasn't changed at all. In other words, many use cases that currently work in a transparent manner will require "force save" to be turned on, which can lead to confusing situations when updating the library.

=> As far as retrocompatibilty goes, I'd rather make "force save" enabled by default and let people disable it when they want to focus on performance.

Would you be okay with that @sandreas ?

Zeugma440 avatar Jun 11 '22 08:06 Zeugma440

=> As far as retrocompatibilty goes, I'd rather make "force save" enabled by default and let people disable it when they want to focus on performance. Would you be okay with that @sandreas ?

Absolutely, I think it is very important not to break existing software by changing the default behaviour. Since I implement many things by myself (see https://github.com/sandreas/tone/blob/8066911e74302c6d6e18640c7c52f8f83da3d6f9/tone/Metadata/MetadataTrack.cs#L10), this is the perfect behaviour.

Thank you for thinking this through :-)

sandreas avatar Jun 12 '22 11:06 sandreas

Developing tone I came up with an idea that would have a lot of benefits...

How about the Track class tracking the changes made to metadata in a History / UndoManager with access to original properties?

Maybe an extension Class TrackableTrack ;)

That would make the implementation of this feature pretty easy (no changes, no save) and you could access differences between the original and the existing without reloading the file or stream again.

What do you think?

sandreas avatar Aug 25 '22 07:08 sandreas