Uploaded image for project: 'Picard'
  1. Picard
  2. PICARD-2909

libopus fails to read METADATA_BLOCK_PICTURE without bit depth set

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Normal Normal
    • 2.13.3
    • 2.11
    • Tags & Metadata
    • None

      I have used a "real world" audio sample for this bugreport in order to make the results, including fingerprinting and tagging in Musicbrainz Picard reproducable.

      The attached audio sample is from this release: https://archive.org/details/BSOG0006/01-TheBurnsWeEarn_192kb.mp3

      The license looks okay for the purpose of attaching it to a bugreport.

      This is the corresponding album on musicbrainz: https://musicbrainz.org/release/c652ba28-390d-44a1-9eab-054ef41a1770

      The sample has been transcoded to OPUS using ffmpeg n6.1.1 built with libopusenc 0.2.1-4. It has then been tagged using Musicbrainz Picard 2.11 which results in the cover art being embedded. ffprobe describes the resulting file as follows:

      [ogg @ 0x5a704ad78e00] 1579 bytes of comment header remain
      Input #0, ogg, from 'tagged_01 The Burns We Earn.opus':
        Duration: 00:02:22.36, start: 0.000000, bitrate: 33 kb/s
        Stream #0:0: Audio: opus, 48000 Hz, stereo, fltp
          Metadata:      MUSICBRAINZ_RELEASEGROUPID: 14a4f11e-0813-4bd3-80a6-f3b7150d63d7
      [...lots of metadata left out here...]
        Stream #0:1: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 500x500 [SAR 1:1 DAR 1:1], 90k tbr, 90k tbn (attached pic)
          Metadata:
            comment         : Cover (front)
      

      The resulting mediafiles are attached.

      When opening the file tagged_01 The Burns We Earn.opus in Audacious 4.3.1 the cover art is not parsed and displayed. The process fails with the error

      ERROR ../audacious-plugins-4.3.1/src/opus/opus.cc:142 [read_image_from_tags]: Error parsing METADATA_BLOCK_PICTURE in file:///tmp/testme/testcase/tagged_01%20The%20Burns%20We%20Earn.opus. 
      

      Running opusinfo from opus-tools 0.2 against the tagged file results in...

      WARNING: Invalid picture parameters in METADATA_BLOCK_PICTURE comment 31 (stream 1): width (500), height (500), depth (0), and colors (0) MUST either be set to valid values or all set to 0
          METADATA_BLOCK_PICTURE=3|image/jpeg||500x500x0|<26588 bytes of image data>
      

      ...which indeed violates the format definition for METADATA_BLOCK_PICTURE as laid out here: https://www.opus-codec.org/docs/opusfile_api-0.6/structOpusPictureTag.html#a9af23c314edf9a995c95a4d28f49eac0

      I guess, the easiest way would be to just not set the image size at all, as the output of opusinfo suggests.

      backlink to the issue in the Audacious bugtracker: https://github.com/audacious-media-player/audacious/issues/1387

          [PICARD-2909] libopus fails to read METADATA_BLOCK_PICTURE without bit depth set

          I added a change to not fill width and height for Opus files. The behavior for other Vorbis based formats stays unchanged.

           

          This is also backported to Picard 2.x and will be included in the bugfix release we will release next week.

          Philipp Wolfer added a comment - I added a change to not fill width and height for Opus files. The behavior for other Vorbis based formats stays unchanged.   This is also backported to Picard 2.x and will be included in the bugfix release we will release next week.

          GitHub Bot added a comment -

          See code changes in pull request #2580 submitted by phw.

          GitHub Bot added a comment - See code changes in pull request #2580 submitted by phw .

          glanduin added a comment -

          I just opened this account to ask about this bug. My archive consists of "opus" files and still, when i tag new files with picard, the cover art is not shown in audacious (and few other apps). So i assume this is still an issue.

          glanduin added a comment - I just opened this account to ask about this bug. My archive consists of "opus" files and still, when i tag new files with picard, the cover art is not shown in audacious (and few other apps). So i assume this is still an issue.

          Alternative to setting the color depth could be to indeed leave all values at 0, but only for opus files and no other format with Vorbis tags.

          Philipp Wolfer added a comment - Alternative to setting the color depth could be to indeed leave all values at 0, but only for opus files and no other format with Vorbis tags.

          Just setting all data to 0 is likely not an option, then we just have to wait for the next reported issue with that (see e.g. PICARD-455 for a past issue).

          If I read the opusfile source code correctly it expects the color depth to be set if width / height are set, so that's probably what we should try to do.

          ..which indeed violates the format definition for METADATA_BLOCK_PICTURE as laid out here: https://www.opus-codec.org/docs/opusfile_api-0.6/structOpusPictureTag.html#a9af23c314edf9a995c95a4d28f49eac0

          Not quite sure where you read this from, the link explains the structure for holding the data from this tag. Nothing there indicates that there is something wrong.

          The specific expectations that none or all of the values must be 0 seems to be an implementation specific thing in the opusfile library.

          Philipp Wolfer added a comment - Just setting all data to 0 is likely not an option, then we just have to wait for the next reported issue with that (see e.g. PICARD-455 for a past issue). If I read the opusfile source code correctly it expects the color depth to be set if width / height are set, so that's probably what we should try to do. ..which indeed violates the format definition for METADATA_BLOCK_PICTURE as laid out here: https://www.opus-codec.org/docs/opusfile_api-0.6/structOpusPictureTag.html#a9af23c314edf9a995c95a4d28f49eac0 Not quite sure where you read this from, the link explains the structure for holding the data from this tag. Nothing there indicates that there is something wrong. The specific expectations that none or all of the values must be 0 seems to be an implementation specific thing in the opusfile library.

            outsidecontext Philipp Wolfer
            hlinden Harald Linden
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:

                Version Package
                2.13.3