under Windows XP x64 Edition. The ID3 tags are created as v1.0 for mp3's (set to ID3 v2 only and v2.3 for ID3 v2 tag creation), verified as version 1.0 by Winamp. Re-trying with DSP effect... same result.
New twist: a few of the tracks I tagged in the batch did use the proper settings (ID3 v2.3 UTF-16), maybe one of every five or so - it doesn't seem to have anything to do with mishandling long file names.
Mp3 Lame Encoder: Forcing Frequency or Channels (on advanced) can crash CoreConverter
Affected: Release 12.0
Fixed in R12.1
http://www.dbpoweramp.com/dmc.htm
Final bit of info: This doesn't appear to be a problem with the utility codec at all. After stripping the ID tags from files and creating them using the explorer Edit ID Tag option, dMC still ignores my settings for tag creation most of the time and makes ID3 v1 tags only - I tried various settings (Ape, ID3v1+v2, etc.) and dMC just makes ID3 v1. Also tried rebooting after changing settings with no effect.
If you convert another file to mp3 and hold the mouse over mp3, what tags does it say there are. In dbpoweramp configuration, do the mp3 tagging options stick (ie next time you go back in is it what was last set?)
Conversion to ogg, m4a, and transcoding to mp3 (all from mp3) create proper tags. The dbpoweramp configuration settings all stick, both within a windows session and after logging off/restarting. So far only tag creation from untagged files and updating ID tags has failed to use proper mp3 tag settings from configuration, and it doesn't always fail (works for about 1 in 10 files, same result for a given file, no identifiable pattern in file names or sizes).
I also tried re-naming an improperly tagged file to a filename that worked, still gets tagged improperly. All the files I'm trying are encoded by the same encoder at the same bit rate (112 CBR).
On the plus side, the ID tag utility itself seems to function without problems, I've tried out all the options (stripping, remapping, deletion, case changing, and addition) and they work without any bugs for me. I appreciate the near-live support; I'm done for tonight, but I'll check back tomorrow.
Ok, one last bit of info :-) If I use winamp to update an improperly handled file, it converts the ID tag without issue. If I then run the ID tag updater on the improperly handled file with a new (Winamp) ID3 v2.3 tag, it reverts to ID3 v1
Ok, so if I strip the ID tag from a file that works, the first frame header starts at byte 0, with an ID3 v2.3 tag it inserts the tag at the beginning of the file so the first frame header starts at byte 2048. The improper files always have the first frame header at byte 0 regardless of whether they are tagged (v1) or not. If they are tagged, the tag is at the end of the file identified by the hex string 54 41 47 [TAG], text-identifiable elements (like artist, album name, etc) follow. The interresting bit is that there is another TAG section: 54 41 47 followed by 122 bytes of hex 20 and terminating in 00 00 FF - this preceeds the actual ID3 v1 tag if it's present. It remains even if I strip all ID tags, so I'm guessing that the fact that the bogus TAG identifier is followed by a bunch of 20 20 20 20 hex code instead of actual empty 00 00 00 00 space causes dbpoweramp to not strip the section, but also makes it choke when attempting ID tag manipulation.
That's it; if I manually hex edit a legitimate ID3 v1 tag in place of the faulty one (or if I strip it altogether), dbpoweramp handles the file properly. I don't really know how feasible it would be to to add IMPROPER ID tag stripping to the utility, since improper ID tags could conceivably take almost any form, but you might be able to work a solution for improperly tagged files whereby the program recognizes certain forms of improper tags (i.e. the variety that causes it to fail to add ID3 v2 tags) and removes them, while completely ignoring other forms of improper tags. No idea if that's possible/within the realm of what you want to do - my own coding skills are pretty limited.
Comment