[SOLVED] Cover images not loaded for all albums

[haeckse]

@Nutul @TheOldPresbyope thank you guys for looking into the issue. I have put a file whose album art does not show up here:


https://drive.google.com/file/d/1Lv_1sp2...share_link

A note that might be helpful: It's been many years since I sampled my CD collection, but I seem to remember that among other tools I used iTunes to sample a lot of CDs. I also added cover images to the songs with iTunes, which maybe is the reason that in some songs the album art images are strangely attached in mjpeg format:

Code:

Input #0, mp3, from '01 Wolken ziehen vorbei.mp3':
  Metadata:
    title           : Wolken ziehen vorbei
    artist          : 2raumwohnung
    album           : Es wird Morgen
    track           : 1
    genre           : Dance
    iTunNORM        :  000006AD 00000437 00004FCC 000033AA 0003EEFB 0003EEFB 00008000 00008000 000074A4 000092C1
  Duration: 00:04:36.17, start: 0.000000, bitrate: 89 kb/s
    Stream #0:0: Audio: mp3, 22050 Hz, stereo, fltp, 80 kb/s
    Stream #0:1: Video: mjpeg (Baseline), yuvj444p(pc, bt470bg/unknown/unknown), 600x600 [SAR 300:300 DAR 1:1], 90k tbr, 90k tbn, 90k tbc (attached pic)
    Metadata:
      comment         : Other

Regards,
Andrea

Hi,

I have tried several adjustments, to see what eventually was wrong, and found that the file uses a ID3v2.2.0 tag format.
I changed the track number to 2, then back to 1, and saved the changes (using Kid3), and this was enough to have Kid3 convert the TAG in ID3v2.3.0, and moOde is now happy displaying the album art.


It has also this (marked invalid by Kid3, probably unrecognised...) tag entry: iTunNORM, containing the following string:

00000688 0000071E 00005784 0000692A 000349E7 000349E7 0000798F 00007AD3 00024A4D 0000FA28

which gets into the COMMENT tag and may result annoying in the TAG view of moOde... Anyway, this is not the cause of the issue.


I'll have a look into the ID3 tag parser, to see if it is the library we use being not able to parse the v2.2.0 version, or just a flag looking specifically for a v2.3.0 and higher.

ETA:
Indeed, the Zend library ID3 parser wants either a version 3 or 4 tag:

Code:

if ($this->_header->getVersion() < 3 ||
           $this->_header->getVersion() > 4) {
           require_once 'Zend/Media/Id3/Exception.php';
           throw new Zend_Media_Id3_Exception
               ('File does not contain ID3v2 tag of supported version: v2.' .
                $this->_header->getVersion());
       }

and the file header is as follows (note 02 00 declaring a v2.2 version):

Code:

49 44 33 02 00 ...

The differences between v2.2.0 and v2.3.0+ render the two tags almost completely incompatible (the main thing being the frame identifiers 3 bytes long for v2.2.0, and 4 bytes long for v2.3.0+ requiring the whole set of frame parsers to be re-implemented or, in the best scenario, at least re-mapped), and, IMHO, it's not worth the effort of extending the library, also considering how easy it is to convert the tags themselves.


So, to be on the safest side, I suggest you convert all the tags to v2.3.0. Even better to v2.4.0, as it will allow for multiple genre tracks to be properly parsed and categorized by moOde, as I see from this file you probably are using.

I don't know what OS you are under (the tags suggest Win32), but you better search for command-line tools allowing for that, as it might be tedious to do it by hand on a graphical tool.

Hi Al,

Thanks again for looking into it and finding the root cause.

As mentioned, back in days I've used many different tools for ripping my CDs on a Windows machine, which seemingly led to a pretty messed up audio library. The iTunNORM entry has been presumably created by iTunes and is somehow related to volume levels respectively normalisation. 

Anyways, the sad days of working on Windows machines are long over, so I will have a look for a neat command line tool to perform some batch conversion of the ID3 versions and structures.

Cheers,
Andrea