WavInfoTag's fields are null terminated

[Dan Gravell]

Inside WavMetadataNewTagsId3BeforeInfoTest.testModifyFileMetadataSaveBoth() there's:

        assertEquals("artistName\0", tag.getFirst(FieldKey.ARTIST));

Why the null terminator? Shouldn't this return a value more useful to the client?

Can we just trim null terminators from the read fields?

I noticed there's one \0 between each field in the LIST INFO chunk, but some fields sometimes have this additional \0 included within the length of the value.

In the case of test123.wav there's the additional \0 for the "artistName" but not the "albumName".

[IJabz]

I found that Windows Explorer does not show the last character unless the value ends with a null terminator, so I think all the fields now have a null temrinator added when written to INFO chunk

https://bitbucket.org/ijabz/jaudiotagger/commits/df31724495e3f1528006b3a1b69f88a395203ba6

but not ID3 chunk, Then if that means the field is not even no of bytes we then add another null character, that accounts for difference between artistName and albumName and that is why there is null bytes in the actual file. * Can we just trim null terminators from the read fields?* Don't know really, but I think modifying it might well break the code Im not really very keen to modify. In my code since I always prefer ID3 to INFO the problem doesnt come up because the ID3 fields do not have the trailing null

[Dan Gravell]

Interesting about Windows Explorer. Here's another reference:

https://sourceforge.net/p/bwfmetaedit/bugs/22/

So I agree you might want to write the field with a null terminator (with an extra one for even number of bytes, thanks for that clarification) if this has become de facto because Windows Explorer requires it, but shouldn't the get methods still return the data without the null terminator? It's not like Explorer shows the null terminator, so why should JAT?

The set methods should add the terminator at the time of writing, I would've thought...

[IJabz]

Well because JAT should return the data in the field, and this null terminator is part of the field, its not part of the WAV spec its being added to support Windows Explorer. If I just trimmed then JAT can no longer tell you if the field does or does not contain a trailing null

At the time of writing during the sync process it does indeed added null terminators to fields in the InfoTag if they are missing, ibut it wouldnt make sense for the set methods to do this since we only want to add for INFO tag not ID3 tag

[Dan Gravell]

Ok, I see what you mean now. I actually found it difficult to find a definitive spec for the INFO chunk. You're right, if the null is not described in the spec, it should be returned. A bit annoying!

I've actually found a bug relating to this I'll file now.

[Dan Gravell]

Working as described - the null terminator does not form part of the RIFF spec and so it should be returned as it is the contents of the file.