#33 Patch fixing bug 3572036 (On Windows, id3v2 corrupts ID3V1

[Granville Moore]

This is a fix for bug 3572036 (On Windows, id3v2 corrupts ID3V1 frames of genre "Ambient").

Issue
If a media file which has an ID3V1 tag indicating the genre "Ambient" is written to by id3v2, the file is truncated by 1 byte, resulting in corruption of the ID3V1 tag.

The exact consequences depend on the operation that was attempted. If the attempted operation was to delete the ID3V1 frame, this fails, and 255 bytes of the tag remain (now invalid and unrecognisable by id3v2). If the attempted operation was a field modification or addition, the existing ID3V1 frame is truncated by one character, and a whole new tag is appended containing the modified data. Repeated modification operations result in a chain of corrupted id3v1 tags being appended to the file.

Cause
This is caused by id3v2 attempting to check that it has adequate permissions to perform the desired operation, by opening the file briefly and then closing it. It does this in text mode, however, instead of binary. On unix/linux, this has no consequences, but on Windows (VC6.0 only tested to date) opening a text file that ends in 0x1A (Ctrl-Z) causes this last character to be discarded. This is because Windows sees Ctrl-Z as an "End of File" marker. This affects ID3V1 frames of genre "Ambient" because the last byte of the ID3V1 frame indicates the genre, and the genre "Ambient" is represented by the value 0x1A.

Comments describing the truncation operation exist in the VC6.0 standard I/O library file "Program Files\Microsoft Visual Studio\VC98\CRT\SRC\OPEN.C" which states:
/* We have a text mode file. If it ends in CTRL-Z, we wish to remove the CTRL-Z character, so that appending will work. We do this by seeking to the end of file, reading the last byte, and shortening the file if it is a CTRL-Z. */

Fix
The solution to this issue is to perform the open operation that is used to verify access permission permissions in binary mode rather than text.

(Note that additional modifications to the distributed code are required to make it compile on Windows, due to the need to include different library paths, etc, but that is a separate issue, and this is a specific data-corrupting bug)

Data Recovery
Corrupted files can be identified by the presence of the ID3V1 frame header characters "TAG" starting either 255 bytes before the end of the file (in the case of a failed frame deletion), or 511 bytes before the end of the file (in the case of a failed frame modification). Note that multiple corrupt frames may be present. Recovery is relatively easily done using a hex editor to remove the corrupted frames and re-insert the missing 0x1A genre marker. Note that even a bugfixed version of id3v2 will not recognise or remove the corrupted ID3V1 tags, because the corrupt ID3V1 frame does not have the expected length (it has 255 instead of 256 chars).

[Granville Moore]

Patch fixing bug 3572036 (On Windows, id3v2 corrupts ID3V1 frames of genre "Ambient")