FLAC Embedded Album Covers

[rb0135]

Hi Rob,

I was able to repro the issue. Only the Doors embedded cover is displayed. I looked at the files with Mediainfo and did not see anything suspicious.

I don't have any other tools to analyze the files so maybe u can look at them with a tag editor and see if there is anything unusual with the embedded images.

-Tim

Hi Tim,

I'm glad in one way that it does the same for you and it is not just me.

All good, I will play around with the files and see if I can get it working.

I actually found a few MP3 files over the past few hours that are behaving like that as well. 

It must be deformed ID tags.

Thanks for your help. I'll report back once I solve the issue.

Thanks,
Rob

[rb0135]

I have had a number of various problems with tagged images etc, the best solution I found was to delete all tag info and start again.

Hi kit1cat.

I'm thinking you might be right, although every other program I have displays the embedded image without an issue.

[rb0135]

Hi Rob,

I was able to repro the issue. Only the Doors embedded cover is displayed. I looked at the files with Mediainfo and did not see anything suspicious.

I don't have any other tools to analyze the files so maybe u can look at them with a tag editor and see if there is anything unusual with the embedded images.

-Tim

Try VLC, my favorite Swiss-Army knife, available on most platforms. It should show the image in a media file if present.

FLAC is not MP3. See https://xiph.org/flac/index.html for a discussion of its format scheme.

Regards,
Kent

Hi Kent,

Every other program I have displays the embedded image without an issue (especially VLC). I use MP3TAG to tag my MP3 and FLAC and it shows the image.

No one said MP3 and FLAC are the same. 

Thanks,
Rob

[BigScaryTiger]

I had the same problem... where for no discernable reason Moode would not show coverart that would appear in Rune.
In the end I discovered a sister program to DbPoweramp called PerfectTunes
https://www.dbpoweramp.com/perfecttunes.htm

Over a week and a bit I was able to fix the missing artwork in my library. Not the simplest or cheapest solution, but I can vouch it worked.

[TheOldPresbyope]

Hi Rob,

I was able to repro the issue. Only the Doors embedded cover is displayed. I looked at the files with Mediainfo and did not see anything suspicious.

I don't have any other tools to analyze the files so maybe u can look at them with a tag editor and see if there is anything unusual with the embedded images.

-Tim

Try VLC, my favorite Swiss-Army knife, available on most platforms. It should show the image in a media file if present.

FLAC is not MP3. See https://xiph.org/flac/index.html for a discussion of its format scheme.

Regards,
Kent

Hi Kent,

Every other program I have displays the embedded image without an issue (especially VLC). I use MP3TAG to tag my MP3 and FLAC and it shows the image.

No one said MP3 and FLAC are the same. 

Thanks,
Rob

Sorry, I was in a hurry to leave and ended up with what sounds snarky when I read it now.

The point I failed to make is that FLAC has its own scheme for metadata and various editors do or do not write strictly valid entries. Some players are more lenient than others about it. I haven't explored the Zend modules which are pulled into moOde to deal with the various file types but it's possible Zend/Media/Flac.php is having heartburn over some of your files or it's returning data which moOde's coverart.php throws into the proverbial bit-bucket.

I don't have a library of FLAC files to test. I just downloaded one I found on the Interweb which VLC can play and display the coverart. moOde can also play it but not display the coverart. Similarly the very useful tool easyTAG can display its basic audio info and its textual metatags but not its coverart. I'm thinking one could use the Python mutagen module to analyze the file contents in detail, but no promises here.

In the above I use the word "coverart" loosely. FLAC has the METADATA_BLOCK_PICTURE which can contain many pictures of different "picture type". The MIME type of each picture is mandatory. yada yada yada. That's why I pointed to the spec.

Regards,
Kent

[TheOldPresbyope]

Hi Rob,

I was able to repro the issue. Only the Doors embedded cover is displayed. I looked at the files with Mediainfo and did not see anything suspicious.

I don't have any other tools to analyze the files so maybe u can look at them with a tag editor and see if there is anything unusual with the embedded images.

-Tim

Try VLC, my favorite Swiss-Army knife, available on most platforms. It should show the image in a media file if present.

FLAC is not MP3. See https://xiph.org/flac/index.html for a discussion of its format scheme.

Regards,
Kent

Hi Kent,

Every other program I have displays the embedded image without an issue (especially VLC). I use MP3TAG to tag my MP3 and FLAC and it shows the image.

No one said MP3 and FLAC are the same. 

Thanks,
Rob

Sorry, I was in a hurry to leave and ended up with what sounds snarky when I read it now.

The point I failed to make is that FLAC has its own scheme for metadata and various editors do or do not write strictly valid entries. Some players are more lenient than others about it. I haven't explored the Zend modules which are pulled into moOde to deal with the various file types but it's possible Zend/Media/Flac.php is having heartburn over some of your files or it's returning data which moOde's coverart.php throws into the proverbial bit-bucket.

I don't have a library of FLAC files to test. I just downloaded one I found on the Interweb which VLC can play and display the coverart. moOde can also play it but not display the coverart. Similarly the very useful tool easyTAG can display its basic audio info and its textual metatags but not its coverart. I'm thinking one could use the Python mutagen module to analyze the file contents in detail, but no promises here.

In the above I use the word "coverart" loosely. FLAC has the METADATA_BLOCK_PICTURE which can contain many pictures of different "picture type". The MIME type of each picture is mandatory. yada yada yada. That's why I pointed to the spec.

Regards,
Kent

I've done some more digging on this issue.

The tool "metaflac" was most useful (it's part of the flac command line tools, available in most Linux repositories; don't know about Windows/MacOS). Here's a partial report for a flac file containing an image which displays in moOde and is found by Linux-based tools I have like easyTAG

Code:

dummy@T520 ~/Music $ metaflac --list test3.flac
METADATA block #0
 type: 0 (STREAMINFO)
 is last: false
 length: 34
 minimum blocksize: 1152 samples
 maximum blocksize: 1152 samples
 minimum framesize: 1650 bytes
 maximum framesize: 6130 bytes
 sample_rate: 96000 Hz
 channels: 2
 bits-per-sample: 24
 total samples: 3828096
 MD5 signature: e5d100c63f5188900c66b6a6a08ce2eb
METADATA block #1
 type: 4 (VORBIS_COMMENT)
 is last: false
 length: 149
 vendor string: reference libFLAC 1.2.1 win64 20080709
 comments: 5
   comment[0]: ALBUM=Bee Moved
   comment[1]: TITLE=Bee Moved
   comment[2]: ALBUMARTIST=Blue Monday FM
   comment[3]: MRAT=0
   comment[4]: ARTIST=Blue Monday FM
METADATA block #2
 type: 6 (PICTURE)
 is last: false
 length: 58388
 type: 3 (Cover (front))
 MIME type: image/jpeg
 description: image/jpeg
 width: 0
 height: 0
 depth: 0
 colors: 0 (unindexed)
 data length: 58336
 data:
   00000000: FF D8 FF E0 00 10 4A 46 49 46 00 01 01 00 00 01 ......JFIF......
   00000010:

Doing the same with the flac file I mentioned before (image displayed by VLC but not by moOde nor found in my other tools) shows no type 6 (PICTURE) metadata block is contained in the file.

Candidly, I'm mystified how the image is encoded in this file and how VLC finds it. It is not hiding, for example, in a PADDING metadata block (I looked) nor does it affect the flac decoder. I'll be interested to hear what metaflac has to say about your flac files.

As an aside, I've run across comments on the web about users getting into trouble editing flac files with MP3TAG. Caveat utilitor. As an exercise I installed v2.88a in PlayOnLinux and looked at my mystery file. It didn't find an image either, although it does in the case of flac files which contain an image encoded in a flac-metadata block type 6.

Bottom line: I have no reason to believe moOde is misbehaving with flac imagery.

Regards,
Kent

[rb0135]

Kent,

Thanks for all that information.

However, your bottom line is wrong. MoOde is the problem (well the routines moOde uses) as I too have spent a lot of time with this lately.

I have included images of both VLC and RUNE displaying the correct album cover, yet moOde is not. It shows the cover from the first song in the list. Even every other Tag program I used displays the covers correctly.

Now, I have used 5 different Tag programs to test, including MP3TAG. PerfectTunes was the worst and any image loaded into a flac file with PerfectTunes would cause moOde not to show any covers. I settled on using TagScanner as it was able to find tag information easily from Sources.

When using the 5 programs, I deleted ALL tag information and recreated the tags from internet sources as to hopefully have a clean file.

I even went to the point of changing the covers.php file to log errors when reading Flac files however, it never came back as an error. I haven't had the time to look more into the routine (cant remember the name of it now) to add some debug info.

Don't get me wrong, I am not bagging moOde. But, now that I have chosen it, I want it to be 100% for me, and all I do is to play MP3 or FLAC files in my home cinema setup, and I just want the right album cover shown, that seems all other programs can show.

Here are the images. All of these loaded the exact same FLAC file from the NAS:

Correct cover shown in VLC



Correct cover shown in Rune



Incorrect cover shown in moOde



Appreciate all the assistance so far. I'm trying to help myself as much as well.

Thanks.

[Tim Curtis]

Hi,

moOde uses the Zend Media library for fetching embedded cover art from MP3, FLAC, AAC and ALAC formats. AFAIK Zend Media is the only PHP lib that supports ALAC format.

Your could try to debug the library module. Have a look in /var/www/inc/Zend/Media

-Tim

[TheOldPresbyope]

Kent,

Thanks for all that information.

However, your bottom line is wrong. MoOde is the problem (well the routines moOde uses) as I too have spent a lot of time with this lately.

I have included images of both VLC and RUNE displaying the correct album cover, yet moOde is not. It shows the cover from the first song in the list. Even every other Tag program I used displays the covers correctly.

...

Well, I've been known to be wrong before 

However, the fact remains as stated in the FLAC FAQ

What kinds of tags does FLAC support?

FLAC has it's own native tagging system which is identical to that of Vorbis. They are called alternately "FLAC tags" and "Vorbis comments". It is the only tagging system required and guaranteed to be supported by FLAC implementations.

Out of convenience, the reference decoder knows how to skip ID3 tags so that they don't interfere with decoding. But you should not expect any tags beside FLAC tags to be supported in applications; some implementations may not even be able to decode a FLAC file with ID3 tags.

The FLAC spec says images shall be encoded in occurrences of the METADATA block type 6 (Picture) Vorbis comment. Every instance of FLAC file at my disposal, save one, contains such a block (as reported by metaflac and mutagen, to cite just two examples) and the encoded image in the block is properly decoded and displayed in moOde. This is the basis of my statement.

When I create a playlist arbitrarily selecting single tracks from different albums of such FLAC files, the appropriate cover art is displayed as each new selection begins playing in moOde.

Would you be willing to PM to me at least two files (or link to same) which demonstrate your problem?

That one FLAC file I mentioned, which I downloaded at random from the Internet, contains an image which VLC displays but which isn't found by moOde, metaflac, or Mp3tag, to cite three examples. I'm going to dissect it and I'd like a go at yours as well.

There's the possibility that the image in my file and in yours is encoded inside an ID3 tag. Once the FLAC file signature ("fLaC") is detected at the beginning of the file, all the media tools I have switch to scanning for Vorbis comments, as, I suspect, does the Zend media library. They then may very well skip ID3 tags just as the FLAC reference decoder does. No error results because "nothing to see here." Hence the need for dissection.

As a result of this thread and the feature-request thread about composer lists started by @timbarnes, I'm on a deep dive into tagging schemes and supporting tools. Along the way I've come to distrust tag editors with respect to them reporting what's actually in a file. They try too hard to hide the sausage-making from the user. 

-----

The "incorrect" cover art displayed for your Ziggy Stardust tracks (Ah, those were the days!) is a common result when media players reach out to the Internet for an image. The matching scheme is primitive and not just for the modules included in moOde: 

I have an MP3 track of Iz (Israel Kamakawiwo'ole) singing Somewhere Over the Rainbow. It was a demo track which didn't come with cover art. Playing it, Groove Music on my Windows 10 box displays the cover to the soundtrack album of the movie "Meet Joe Black". I have seen various misfires with cover art when I misguidedly let auto-tagging tools rip classical CDs.

-----

As an aside, the most recent Rune Audio codebase I could find is 2 to 4 years old. The coverart.php module in it uses the Zend media library to look for a "Picture" METADATA block in FLAC files just like moOde does [ahem, not surprising]. I have no idea what their current code does.

Regards,
Kent

[Tim Curtis]

The Rune Git repo indicates they are using getID3 media file parser. Its a nice lib but doesn't support the ALAC format. Looks like they also use Last.FM cover lookup as a fallback.

Zend is only PHP lib that I'm aware of that supports ALAC which is why I use it moOde, and I don't include a fallback to online lookup primarily because it can mask broken embedded art and can return the wrong cover.

Cover art fails are relatively rare anyway IME so I've never felt the need to try and use something like getID3 for some formats and Zend for others. That gets kind of messy.

-Tim