Errors with opus files previously tagged with picard/mutagen

[iconoclasthero]

While using beets I found all but 9 of 455 .opus files were "unreadable."
Upon further investigation I found that they were also not readable in picard, however they were all previously tagged by picard.
An album, James McMurtry's Saint Mary of the Woods has a timestamp of 03-2023 with MBDB tags in it that is now not readable by mutagen 1.46.1, 1.47.0, and 1.47.1 on two different ubuntu 22.04 machines with python 3.10.12 on them.

NB: I've been using the /etc/apt/sources.list.d/musicbrainz-developers-ubuntu-daily-jammy.list ppa for picard.

The files play fine with VLC and ffplay, works with ffmpeg, no obvious errors from ffplay.
ffmpeg -acodec copy produces files that mutagen can use, indicating no issue with the underlying data.

Here's the mutagen version and errors with picard trying to load the McMurtry .opus files:
picard error.log

ffprobe & mediainfo of a song:
ffprobe.log

[iconoclasthero]

All 59 of the .wma files I have are also not readable by 1.46.1 and 1.47.1 of mutagen.
Again, vlc, ffprobe report no errors on this The Gourds -- Bolsa de Agua album I'm listening to....
Oh, these all apparently play on mpd too, but there are some issues that mpd is reporting, but then again, vlc isn't and it is mpd...

Here's the wma with mediainfo, ffprobe, vlc, mpd, and picard...

wma.log

[iconoclasthero]

There was an .opus album that was working and the remuxed (?) ffmpeg -acodec copy output from the McMurtry album...
mediainfo and ffprobe info:
working.log

[iconoclasthero]

Here's some info on what wrote these files:

$ find /library/music -iname "*opus" -exec sh -c 'mediainfo "{}"|grep -E ete\ name\|Writing' \;|sort|uniq -c|tail -20
      1 Complete name                            : /library/music/Yola/Yola Carter -- Orphan Offering (2016) (mp3)/Yola Carter -- 06 - Fly Away.opus
    287 Writing application                      : Lavc57.107.100 libopus
     20 Writing application                      : Lavc58.35.100 libopus
      3 Writing application                      : Lavc58.54.100 libopus
     10 Writing application                      : Lavc58.60.100 libopus
      2 Writing application                      : Lavc60.6.101 libopus
     25 Writing application                      : Lavf57.83.100
     14 Writing application                      : Lavf58.29.100
     12 Writing application                      : Lavf58.34.101
      3 Writing application                      : Lavf58.77.100
     16 Writing application                      : Lavf59.4.101
      1 Writing application                      : Lavf60.4.100
    276 Writing library                          : Lavf57.83.100
     10 Writing library                          : Lavf58.20.100
     17 Writing library                          : Lavf58.29.100
     24 Writing library                          : Lavf58.34.101
      8 Writing library                          : Lavf58.77.100
     16 Writing library                          : Lavf59.4.101
     96 Writing library                          : Lavf60.18.100
      3 Writing library                          : Lavf60.4.100

[iconoclasthero]

lol, i think i've reported this before and it was dismissed then

[phw]

Looking at the error messages this seems to be caused by the issue you had reported at #604: You seem to have run the mid3v2 command line utility on the files, which will just happily add ID3 tags to the start of any file you run it with.

mutagen does not expect an ID3 block at the start of files that are not supposed to have one. This can be nicely seen in the Picard logs, where the file is first tried to be opened as an Ogg Opus file because of the .opus file ending, which fails as the file header does not match (file does not start with OggS. It then tries to detect file type by file header, which in this case is an ID3 block and usually indicates a MP3 file. So it tries to open it as a MP3, but also fails as the rest of the file does not follow the expected structure. Same happens for the ASF

There are probably two things that could be done:

1. Probably mutagen should be able to skip over and ignore the ID3 tags on files where this is not expected and still detect the rest of the file. ffmpeg seems to do exactly that (e.g. for the ASF file ffprobe shows the output "ffmpeg/asf: Discarding ID3 tags because more suitable tags were found.")
2. More importantly mid3v2 should not add ID3 tags to files that are not supposed to have them (changing that might still break someones workflow I fear) I don't think that would be correct, see mid3v2 not working with .opus files. #604 (comment)

In your case In would recommend you run ffmpeg over the files as you did as it will get rid of the ID3 tag block at the start of the file.

EDIT: You can also run mid3v2 -d yourfile to remove the ID3 tags from the affected files, which should make them usable again.

We probably could also add an option to Picard to automatically remove such ID3 tags.