Forcibly Rewriting Tags To Fix Unicode/ISO Numeric Strings Problem

This thread is a "fork" from a bug report, which is about to get off-topic for that bug. The underlying issue that is being discussed here is how to force MP3Tag to rewrite a tag in order to fix the Unicode/ISO issues discussed here and here.

Dano had said:

Interesting - I suspected that it might, but I couldn't prove to myself that it would reconstruct all fields under all circumstances. Cut-Undo had the advantages that it fitted neatly into my (somewhat paranoid, but apparently not quite paranoid enough) workflow (see below), and that it was easily demonstrable that all tags were physically deleted from the file, then re-created.

The reason for uncertainty about whether Save would work is that MP3Tag (all versions as far as I know) doesn't always rewrite tags that it considers to be unchanged. As an example, I have a file with a Unicode TLEN value of 168000. I select it and perform an "Actions (Quick)">"Format Value" to place the (freshly retyped) value of 168000 into the field LENGTH (which is mapped to TLEN). I might have expected that the tag would be rewritten as ISO, but the result is that the file is unchanged - it continues to have a Unicode TLEN (in fact, its timestamp also remains unchanged - the file has not been written at all). If I do this with a different value - writing a value of 168001 into the same file, for example, the file is updated and the format is changed to ISO. The same "lazy writing" behaviour also occurs if the actions are performed as part of an Action Group. It appears that MP3Tag is being "intelligent" and only rewriting fields that it believes have changed. This behaviour is (presumably) aimed at reducing unnecessary writes, and so is a Good Thing. Because of this and a few other observations, however, I was unsure that Save would always rewrite all tags.

The workflow that I was using to rewrite the Unicode tags as ISO was aimed at modifying the absolute minimum of tag data that would make the files playable again. It went like this:

  1. Identify unplayable file in Windows, by enabling viewing of the column "Channels" in Windows Explorer (from observation, this seems to be the most reliable "mass screening" test of a files WMP-playablility, short of attempting to play it. Unplayable files show "0" for Channels. Other fields such as "bit rate" can provide an indication, but Channels is the only field I've found to be 100% reliable, after testing thousands of files).
  2. Create a "local" backup copy of the affected file (in addition to a full backup of all the audio files before starting the whole process)
  3. Run Action Group to forcibly rewrite only the TLEN, TBPM and TDAT tags (and, as far as is possible, no other tags. Because of the "intelligent non-write" detailed above, this requires multiple writes to each tag. I'll post the Action Group details when we've got a a complete "working" version of MP3Tag).
  4. Check again in Windows whether the file is playable
  5. If not, use Ctrl-X to cut all tags from the file.
  6. Check again in Windows whether the file is playable (now it has no tags at all)
  7. If file is still unplayable - file needs fixing/replacing.
  8. If file is playable, use Ctrl-Z to restore and reconstruct all the tags.
  9. Check yet again to see if the file is playable
  10. If file is still unplayable - remove/manipulate tags until it becomes playable.
This process worked OK until I found that tags were being written to the wrong files as a result of the 2.44f cut-sort-undo issue.

I'll post a complete version of this "how to" guide when the 2.44f cut-sort-issue is resolved.

Regards,

gvm