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

No stable sort order for cover art saved to ID3

XMLWordPrintable

      Saving cover art images to ID3 does not store the files in the order they are provided.

      When loading the files back that means the order of cover images differ from the CAA loaded order, resulting in the files being shown as changed.

      This actually is an issue with mutagen reordering the ID3 frames sorted by size. I have not yet tested if this affects other tagging formats as well.

      See also:

          [PICARD-1696] No stable sort order for cover art saved to ID3

          Philipp Wolfer added a comment -

          Ok, my full agreement on this.

          Philipp Wolfer added a comment - Ok, my full agreement on this.

          Sophist added a comment -

          I am sorry that I did not explain myself clearly.

          I agree that the client should ideally not assume that images are presented in a certain order - and Picard should not make this assumption when we can easily program around it.

          However, backwards compatibility (of mutagen) is important, and mutagen should try hard not to introduce backwards compatibility issues.

          Not all cover art types are equally important. I would argue that Front Art is generally going to be considered more important than all other types - so perhaps front art should be saved first. 

          Sophist added a comment - I am sorry that I did not explain myself clearly. I agree that the client should ideally not assume that images are presented in a certain order - and Picard should not make this assumption when we can easily program around it. However, backwards compatibility (of mutagen) is important, and mutagen should try hard not to introduce backwards compatibility issues. Not all cover art types are equally important. I would argue that Front Art is generally going to be considered more important than all other types - so perhaps front art should be saved first. 

          Philipp Wolfer added a comment -

          I think a "it should not matter" response is not really helpful when in reality it does matter. Some clients simply don't look at data too far behind, or use the first image they find.

          Also I think there is value in ordering images, e.g. booklet images make sense to have a certain order.

          Philipp Wolfer added a comment - I think a "it should not matter" response is not really helpful when in reality it does matter. Some clients simply don't look at data too far behind, or use the first image they find. Also I think there is value in ordering images, e.g. booklet images make sense to have a certain order.

          Sophist added a comment -

          I personally agree with what lazka says in https://github.com/quodlibet/mutagen/issues/436 i.e. that mutagen clients like Picard should not rely on the sequence that APIC frames are presented, but should instead program e.g. cover art matches to compare images of a specific type (e.g. front) regardless of sequence. This will require a bit of programming in Picard but shouldn't be that difficult. (Indeed, in Python, it may be possible to use Set objects to do the comparison in a single statement.)

          Sophist added a comment - I personally agree with what lazka says in  https://github.com/quodlibet/mutagen/issues/436  i.e. that mutagen clients like Picard should not rely on the sequence that APIC frames are presented, but should instead program e.g. cover art matches to compare images of a specific type (e.g. front) regardless of sequence. This will require a bit of programming in Picard but shouldn't be that difficult. (Indeed, in Python, it may be possible to use Set objects to do the comparison in a single statement.)

            outsidecontext Philipp Wolfer
            outsidecontext Philipp Wolfer
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:

                Version Package