mid3v2 not working with .opus files.

Question

mid3v2 not working with .opus files.

iconoclasthero opened this issue a year ago · comments

From the README: "Mutagen is a Python module to handle audio metadata. It supports ASF, FLAC, M4A, Monkey's Audio, MP3, Musepack, Ogg Opus, Ogg FLAC, Ogg Speex, Ogg Theora, Ogg Vorbis, True Audio, WavPack, OptimFROG, and AIFF audio files."

I was expecting that the mutagen package would be able to retag the Album/TALB field of .opus files and be able to read them based on the second sentence above. What I found is that it mid3v2 doesn't modify .opus tags and mutagen-inspect does not "load and print information about an [opus] audio file and its tags:"

$ mid3v2 -A "SM (opus)" jm.opus ; mutagen-inspect jm.opus
-- jm.opus
can't sync to MPEG frame
$ mid3v2 -A "SM (opus)" jm.opus ; mediainfo jm.opus |grep -E 'Album|TALB|talb'
Album                                    : Saint Mary of the Woods

Philipp Wolfer · Answer 1 · Mon Mar 27 2023 00:33:50 GMT+0800 (China Standard Time)

Pretty likely your file isn't a Ogg Opus file. If this indeed contains Opus encoded audio it's pretty likely that it is Matroska Opus, but Matroska containers are not yet supported by mutagen (see #3 and #396).

If you have ffmpeg installed, can you run ffprobe [filename] on the file? If the output says something like "Input #0, matroska" then it is a matroska file and unsupported. If it says "Input #0, ogg" it's supposed to work.

Philipp Wolfer · Answer 2 · Tue Apr 11 2023 00:36:10 GMT+0800 (China Standard Time)

The issue got discussed on IRC and it turned out that the reason this brole was that the files got ID3 tags added to them. The command in the issue description also shows that mid3v2 was used on the Ogg Opus file, which is not supposed to be done as Ogg Opus does not use ID3 tags.

Essentially this is not a bug. mid3v2 is not supposed to support Ogg tags, it is a direct replacement for id3v2 command. But a side effect seems to have been that mid3v2 added a ID3 tag block to the file. Not sure if this is inteded or should be prevented.

See the discussion at https://chatlogs.metabrainz.org/libera/musicbrainz/2023-03-27/?msg=5152125&page=2

iconoclasthero · Answer 3 · Tue Apr 11 2023 10:17:10 GMT+0800 (China Standard Time)

I understood Mutagen to be what Picard uses to modify the tags on my .opus files, I further expected that Mutagen did it for all of the files Picard tags and that was apparently fallacious. I took "Mutagen is a Python module to handle audio metadata. It supports ASF, FLAC, MP4, Monkey’s Audio, MP3, Musepack, *Ogg Opus*, Ogg FLAC, Ogg Speex, Ogg Theora, Ogg Vorbis," to mean that the CLI tool that does tagging tags all those files including .opus files, you know, because that is what Picard uses to tag files... I don't know if there's a way to make more clear what mid3v2 does *not* do—of if it's moot since I'm the only one who would see it that way.

…

On Mon, Apr 10, 2023 at 12:36 PM Philipp Wolfer ***@***.***> wrote: The issue got discussed on IRC and it turned out that the reason this brole was that the files got ID3 tags added to them. The command in the issue description also shows that mid3v2 was used on the Ogg Opus file, which is not supposed to be done as Ogg Opus does not use ID3 tags. Essentially this is not a bug. mid3v2 is not supposed to support Ogg tags, it is a direct replacement for id3v2 command. But a side effect seems to have been that mid3v2 added a ID3 tag block to the file. Not sure if this is inteded or should be prevented. See the discussion at https://chatlogs.metabrainz.org/libera/musicbrainz/2023-03-27/?msg=5152125&page=2 — Reply to this email directly, view it on GitHub <#604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEC3GVM4PXNKLPSTWDVBJTXAQZINANCNFSM6AAAAAAWHXTGWQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Philipp Wolfer · Answer 4 · Mon Mar 04 2024 19:33:11 GMT+0800 (China Standard Time)

But a side effect seems to have been that mid3v2 added a ID3 tag block to the file. Not sure if this is inteded or should be prevented.

Actually I think nothing should be changed, as this is exactly the behavior the original id3v2 command also has. You can try it:

touch sometestfile
id3v2 -A "foo" sometestfile

The result is a file that only contains a ID3 block. But you can also run id3v2 on any other file you want and it will add an ID3 block to the start of the file (which will probably break it for other applications).

As mid3v2 is supposed to be a drop-in replacement for id3v2 the current behavior makes sense.