When using Generic Interface with ID3 shouldn't directly return frames but a suitableTagField class should be created

[IJabz]

From https://java.net/jira/browse/JAUDIOTAGGER-413

You add a composer field twice using:

tag.addField(FieldKey.COMPOSER,"composer1"); tag.addField(FieldKey.COMPOSER,"composer2");

internally this is stored in a single TCOM frame with the 2nd value null seperated from the first.

If you go

tag.getFields(FieldKey.COMPOSER,0)

it will return a list containing just one TCOM frame containing both values in its body, this doesnt make much sense. Would be better if the ID3 code create a new TagField for each field added, so that the above call would return two fields each contianing just one value.

Basically the user shouldn't mix and match generic interface with id3 interface, if using generic interface it should only return generic objects. THis could be quite a change, although it is only really an issue when mutiple values are being stored in one frame.

Have a new more problematic case. If you write a date such as 2008-01-01 as FieldKey.YEAR to an ID3v23 tag it currently writes the value to TYER, whereas it writes it to TDRC for ID3v24Tag, however what it should actually do is write 2008 to TYER, and 0101 to TDAT.

This is problematic as it means one field maps to two frames (in contrast the easier problem of things like TRACK_NO and TRACK_TOTAL where two fields map to one frame).

Although we can modify addField() and setField() to add/set two frames instead of one if the calling code uses setField() with both year and dd/mm set it then get complicated knowing what getField() should return as in ID3v23 we cannot create a single frame containing both values and the interface does not allow returning two frames.

Another alternative is that FieldKey.YEAR should just contain the year, and we should add new field keys FieldKey.MONTH and FieldKey.DAY but then we are making it more difficult for ID3v24 because these three fields are stored in just the one TDRC frame (although at least we can treat the same way as we do for TRACKNO,TRACK_TOTAL). We are also making it more difficult for other formats, although the generic key is called YEAR that name is misleading because maps to DATE in VorbisComment/Flac. So if we made three fields we would then have to add extra code to map these three fields to one for these other format.

We cannot just ignore this problem because YEAR is a key field, and ID3v23 is still the preferred format for ID3.

Just to clarify, when you say "what it should actually do is write 2008 to TYER, and 0101 to TDAT" you mean for ID3v2.3 right? According to http://id3.org/id3v2.4.0-frames TYER and TDAT have been removed. Or maybe you are suggesting they should be retained for backwards compatibility with other music players? That's fine of course...

FieldKey.YEAR is your own abstraction which is ok but I wonder if you need to move toward supporting a FieldKey.TIMESTAMP or DATE or TIME or whatever.

For ID3v2.3:

setField(YEAR, "1990") -> sets TYER
setField(TIMESTAMP, "1990-01-01") -> sets TYER and TDAT
getField(YEAR) -> returns contents of TYER

And I suppose the problem occurs when you do:

getField(TIMESTAMP) -> want to return contents of TYER and TDAT

Yes, this is only a problem for V23, v24 is fine. FieldKey.YEAR IS a Date, it is misnamed really but called YEAR because that is what people normally talk about, i.e it maps to DATE field in VorbisComment.

Adding a DATE field doesnt help that much because then adding confusion for other formats sch as FLAC whihc are nice and straightforward at the moment.

Yes the tight coupling is the problem, AbstractID3v2Frame implements TagField so it can be cast to either , but as there is not a one-one mapping between the two its get problematic. Your suggestion of TagField acting as container of frames might be the solution though of course breaks the api somewhat, think I'll have to a hack for I need right now, and provide a better solution in the future.

I wonder if this is a problem for you in bliss, or do you only writes years not dates, or only use ID3v24 not V23 in which case it would not be.

It feels to me like a problem is that the TagField hierarchy is tightly coupled to Frames in the ID3 implementation. Could you have a different implementation of TagField such as AggregatedFrame which combines TagFrames and provides results in some order?