WavTag's SYNC and "active tag" concepts forces movement of data into ID3 tag

[Dan Gravell]

Looks like the way WavTag works when a SYNC option is set is that at read time, the fields are copied from the non-active tag into the active tag.

The trouble with this is that if the file is later commited those fields will be persisted. There are a few reasons this might be bad:

1. We add duplicate fields possibly unexpectedly
2. We might want to maintain the fields in the current tags, for some reason
3. We've not explicitly said we want that behaviour, so this might be surprising

Can we not do this more lazily at getX and setX time? Each call checks the setting in the WavOptions and uses this to prioritise from where the field is read or written.

For addX we'd add to a nominated primary tag.

I think I would prefer more explicit methods to perform synchronisation, if that were required.

Is there a reason it's done the way it is?

[IJabz]

Deal with multiple metadata tags within a single format was difficult, but I dont see how the the WavOptions are not explicit.

For reading it only SYNCS the tags if you select a SYNC option so if you want to maintain existing info just dont use a SYNC option from WavOptions. Then the get() and set() methods just work on the active tag which is alot easier to deal with then trying to update both tags (if you want to keep both) every time you call a set method. Then you can use SYNC at save time to update the non-active tag from the active one if you want to save both or dont use SYNC to save the inactive tag as is.

Sorry I cant see how your solution works or what problem it solves.

[Dan Gravell]

If I don't use a SYNC option, how do I read both tags? I suppose I could cast. But I have instances where a subset of fields are in the ID3 tag, and another subset are in the INFO tag. If I don't sync, I only get the fields from the active tag, right? If I do sync, the subset from the non-active tag are copied to the active tag, which I might not want, and that change may or may not be persisted depending on whether I call commit.

The Javadoc says:

 * The _AND_SYNC versions synchronize the active tag with any additional data that may be available in the nonactive tag
 * after the initial read. For example if the ID3 tag is the active tag but contains no artist tag, but the nonactive
 * Info tag does then the ID3 tag will be initialized with the same value for the artist field.

The way I read this, and the way it appears to work in code is that "sync" means read from the non-active tag and make that available from getX methods. It does not explicitly say or warn that these values will be written if the file is committed. Maybe I missed something...

[IJabz]

So the scenario you describe where you want to look at both tags individually is Wav specific so you can just use WavTag.getID3Tag() and WavTag.getInfoTag(). But for most scenarios they either want to look at only one of the tags or merge all the information into a single tag which is the idea behind the SYNC fields, SYNC would only only return the value form a non active tag if didn't that field didn't exist in the active tag so it doesnt obscure the active tag.

Sure I suppose the Javadoc could be clearer but I cant see a better way for the code to work.

[Dan Gravell]

Ok, I guess I'll cast.

The other way I was suggesting was to only interrogate the WavOptions at getX time, using the option to decide how to prioritise the tags and whether to even go to a secondary tag.

[IJabz]

Yeah I cant see any advantage in that, what might be useful if you could describe your actual specific use case.

[Dan Gravell]

I don't really have a use case, I just have a principle of least surprise, and I didn't expect that using JAT via the generic API would result in these modifications being made, when all I did was read in a file. If I commit a file I have simply read in I don't expect it to make any changes.

Now that I understand the semantics of SYNC though, that it's an "implied" modification, that's all fine. It just wasn't that clear to me. I'll mark resolve.

[Dan Gravell]

The SYNC option is designed to work this way.