Any idea why my .flac files now look like this in DO? They appear fine in Foobar and in MP3TagEditor.
nevermind. It seems that they were written using ID3v2... but DO only supports ID3v1?
Opus supports both ID3v1 and ID3v2.
All of those files have a .MP3 extension, but you said in the subject and your message that they are FLAC files. Which are they? If they're FLAC files when a .MP3 extension then I wouldn't be surprised to see the tags misinterpreted (not that FLAC should have either ID3v1 or ID3v2 tags).
If they are MP3 files then please provide a small example file to test against.
Edit: Just scrolled right and noticed the "320kbps" column so I guess they are .MP3 files. Nothing FLAC about them. 
Send us or GPSoftware a sample and I'm sure someone will take a look.
You say .flac files but the screenshot shows .mp3s...
Opus does support ID3v2 but it's possible the tags have been saved with an encoding type we don't yet support. If you can post an example file I'll have a look.
I'm in the middle of re-encoding my .flac files to .mp3 format and forgot which I was dealing with when I posted. These are legit .mp3 files... the files that I created after converting.
I don't think I can provide a file because once I enabled MP3Tag Editor to write in ID3v1 format, the problem was fixed.
Thanks for the response.
What if you tell the tag editor to write ID3v2 tags for the files again?
You don't want to be stuck using ID3v1, it's awful! (e.g. Really short length limits on all the fields).
I removed the ID3v1 tags and re-saved using ID3v2. I didn't get the same problem... but it's now cutting off some of the tags such as the Artist and Genre. Some of the Titles are shortened (the first one) but not the others so it's not a length issue.
I must say that this area is as embedded with competing standards and general lack of uniformity as anything out there. I can (somewhat) understand the different audio file types/encodes... but not the tags.
FLAC has it's own tag type so there aren't any decisions to make. But for MP3, what's best? ID3v2.3 or ID3v2.4?
Thanks.
ID3v2 specifies multiple encoding types for string tabs (ANSI, UTF-8, etc) so it's possible that there's one of these we've missed or that Opus has a problem with. Again, if you can post an example file we can look at it - just posting screenshots doesn't really help.
I was able to re-create the problem, this time by trying to saving the tags using APEv2.
How do I post a 6MB file?
Opus doesn't support APEv2 tags at the moment, although they should result in nothing showing up rather than corrupt tags. (It's possible the file is tagged with multiple tag formats, in which case it's worth looking at.)
It's a crazy idea, I know, but why not tag a smaller MP3 file? I've attached one that's a 4 second silent track in case you don't have a similar file to hand.
silent.zip (14.2 KB)
i can't seem to re-produce it. I saved the file with APEv2 tags and all of the fields are blank except for duration and bitrate (and size). I tried saving and removing different tag formats but can't reproduce it.
i'll send you a pm with a download link.
Got it, thanks.
The first file has an APEv2 tag so that's why Opus doesn't show anything at all for it as Opus doesn't currently support APEv2.
The second file has both an APEv2 tag (which Opus ignores) and an ID3v2 tag. Whatever wrote the ID3v2 tag appears to have a bug as it's written the Unicode UTF-16 byte-order mark (BOM) incorrectly.
The BOM should be FF FE, or FE FF, but in this file all the strings start with FF 00 FE which is completely wrong as far as I understand ID3v2 and Unicode.
The good news is that it's very easy to detect these bad tags and work around the problem. I've submitted a fix to GPSoftware so you should see the correct tags in the next version of Opus. Whatever wrote the tags has a pretty serious bug, though, as I understand things. (dbPowerAmp could not read the tags either. Foobar2000 does, though, so I guess they have a similar workaround.)