FLAC Embedded Album Covers

[rb0135]

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

Hi Tim,

I have been doing a lot of testing since the post and thanks, I did lookup one of the PHP files and saw the Zend Media Library.

What I have found, is that I am sure there is some caching going on with Zend. I know you mentioned that it doesn't, but, I have the Pi connected via wireless (tried wired as well).

What happens is the first time I play the song, the cover takes maybe 3-4 secs to come up (obviously reading from the file). If I switch to play another song, then come back to the first song, the cover is shown instantly (whether the correct one or not). To me, that means there is some caching going on. Now, I thought browser cache, but it does the same with several browsers, and even when I click on another song, clear the browser cache, then click back on the original, it still shows a cover instantly.

Also, songs that I have had the cover working seem to fail the next day.

I have even used metaflac (as per Kent's previous response) to insert the image into the file and it still doesn't show. Metaflac shows one that the cover always shows and the one that never shows, the metadata is exactly the same (ie: same fields, etc). I even changed the image to a simple 4kb image, and it still didn't show.

I thought about debugging and I have all the tools for .net/aspx but not for PHP. Any ideas on what I could use to debug.

Also, does anyone know where Zend writes its log files. The code seems to throw exceptions to logs so it would be good to see if and why it did.

I'm still testing ideas...

Thanks

[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.

...

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

Hi Kent

Sorry, not saying you were wrong, just the bottom line as like I was also not blaming moOde, but the Zend Media Library (just couldn't remember it at the time).

I replied to Tim (above this) with more testing and results since.

The Ziggy Stardust image is being grabbed by the tag programs or being fetch from the internet at play time. I have tried different images (even made one up in photoshop), used metaflac to remove the original image and add the made up image in, and it still wouldn't show. Metaflac also showed two files, one that works and this one that doesn't, with correct FLAC tagging (by there own standards). Both files have a TYPE 6ICTURE tag in them.

I don't have an issue to PM you two files. Much appreciated that you can afford some time to look at them. I'll do that tomorrow (its 10:15pm here in Sydney).

Other than that, I want to debug Zend as it goes through the process to see exactly why it isn't accepting the image.

Thanks,
Rob

I'm still

[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

Hi Tim,

I have been doing a lot of testing since the post and thanks, I did lookup one of the PHP files and saw the Zend Media Library.

What I have found, is that I am sure there is some caching going on with Zend. I know you mentioned that it doesn't, but, I have the Pi connected via wireless (tried wired as well).

What happens is the first time I play the song, the cover takes maybe 3-4 secs to come up (obviously reading from the file). If I switch to play another song, then come back to the first song, the cover is shown instantly (whether the correct one or not). To me, that means there is some caching going on. Now, I thought browser cache, but it does the same with several browsers, and even when I click on another song, clear the browser cache, then click back on the original, it still shows a cover instantly.

Also, songs that I have had the cover working seem to fail the next day.

I have even used metaflac (as per Kent's previous response) to insert the image into the file and it still doesn't show. Metaflac shows one that the cover always shows and the one that never shows, the metadata is exactly the same (ie: same fields, etc). I even changed the image to a simple 4kb image, and it still didn't show.

I thought about debugging and I have all the tools for .net/aspx but not for PHP. Any ideas on what I could use to debug.

Also, does anyone know where Zend writes its log files. The code seems to throw exceptions to logs so it would be good to see if and why it did.

I'm still testing ideas...

Thanks

Hi Rob,

The cache I was referring to is a not yet developed thumbnail image cache. This is simply a directory of small sized versions of all the cover images. Its typically built as part of a database scan process.

None of the PHP modules in moOde including the Zend Media modules do any sort of explicit image caching. Image and web page caches are maintained by NGINX (the Web Server) and by the client Browser. These caches operate automatically and are necessary for maintaining good performance.

This symptom "Also, songs that I have had the cover working seem to fail the next day." suggests some breakage somewhere and not bugs in the code.

Btw, I typically import CD's using iTunes and ALAC lossless format. I ensure that each track has embedded cover art then I use XLD to convert ALAC to FLAC. Works perfectly and I've never experienced any cover fails or file issues in moOde with either format.

-Tim

[rb0135]

Thanks Tim,

Since XLD is only for a MAC, I cant use it. I use DBPowerAmp converter. I wont go near the ALAC format (or anything to do with Apple) anyway. Would have been something to try I suppose.

Anyway, I am still point fingers at Zend as why does every other program I use.

Ive found some way of debugging the PHP (loose term) through Chrome, so I will try that path and see if I can at least see where Zend "bombs out".

[rb0135]

Ok, after playing around a bit more, I fixed the covers (rather than spending time debugging).

As an experiment, from what Tim mentioned about ripping to ALAC then converting to FLAC, I wondered if I converted to ALAC then back to FLAC would that fix my cover issue.

So, what I did was to use DBPowerAmp to convert the FLAC files to ALAC, then convert straight back to Flac.

Whatever the process did in that conversion, moOde shows the correct cover from the files now.

I tried with a few others that weren't showing, and they show now as well (didn't even have to refresh the library in moOde).

And the ones that I said worked one day and not the next seemed fixed as well.

I made sure I reboot moOde a few times and the correct covers showed after each reboot.

I cant be more happier now with my setup.

I am now pondering do I really need to use FLAC or just keep them in ALAC format. There should be no quality difference right (or should this be another topic)?

Thanks for persevering with this post. At least I seem to have a way to fix the files that just wont display the cover.

[imazed]

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 to disagree that you are looking at a Moode issue.
I have over 5,000 FLAC files and each and every file displays embedded art correctly and has done so since version 3.16.

When I first started tagging my files I had similar problems to you and got fooled into thinking that because some other program displayed a cover, then the problem must be in Moode.  I discovered that some players e.g. VLC default to fetching images from the web if they cannot read the embedded art.  I found that some images could be seen in some players but not others and not all images could be seen in all players.  I had initially used mp3Tag running in windows to add the images.  I ended up switching to Puddletag on Linux.  One reason for doing so was images embedded using Puddletag could be seen by all the players I tested.

[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 to disagree that you are looking at a Moode issue.
I have over 5,000 FLAC files and each and every file displays embedded art correctly and has done so since version 3.16.

When I first started tagging my files I had similar problems to you and got fooled into thinking that because some other program displayed a cover, then the problem must be in Moode.  I discovered that some players e.g. VLC default to fetching images from the web if they cannot read the embedded art.  I found that some images could be seen in some players but not others and not all images could be seen in all players.  I had initially used mp3Tag running in windows to add the images.  I ended up switching to Puddletag on Linux.  One reason for doing so was images embedded using Puddletag could be seen by all the players I tested.

Hi..

That's fine for you to have an opinion and I like to hear from all sides, but, I never said moOde itself was causing the problem (I just said moOde couldn't display the cover) and after a few posts and answers, it seemed that the Zend Media component was having the issue. After testing with about 12 programs (all displayed the cover fine) and even using Xiph's own metaflac to put the cover into the file, moOde was still not receiving the cover from the Zend component.

All my files have been ripped by DBPowerAmp and every bit of software that I've tried (except moOde) could display those covers.

As the countless hours I spent trying to help myself as well as others that might be in the same boat, I found out that Zend only worked correctly with my Flac files if I converted them to ALAC then straight back, meaning there must have been some data that made Zend fail to load.

I should have debugged it to find exactly the cause, but, finding this quick way of converting them to ALAC then back to FLAC fixed the issue for me and I was content enough to leave it there.

Anyway, I'm sure in the near future there will be modifications to the existing metatag data and we'll have to go through the pain again.

Thanks to all that offered assistance in the post.

[leicray]

Hi Rob,

I know that this is a thread that ended around 10 months ago, but I have just encountered the same cover display issues and your solution of converting files to ALAC format and back again to FLAC has worked perfectly for me too.

However, I did notice a change to the cover artwork when I did this. dBpoweramp Music Converter substituted a new (but correct) image file during the conversion process from FLAC to ALAC. I noticed this because the image was slightly less bright (vibrant) in the ALAC file. Presumably, Music Converter parses the tag data and fetches an appropriate image file.

I have also noticed that Mp3tag can sometimes take ages to save FLAC files when I have substituted the cover art in FLAC files created by various programs. On other occasions, the save process is speedy. Must be something to do with Mp3tag having to perform a major reorganisation (not always successfully) of the tag data when saving some files.

Raymond

[TheOldPresbyope]

@leicray

If you happen still to have a .flac track which you know has coverart but moOde doesn't display it, how about putting it on Dropbox or somewhere like it and PM me the link. I'd like to explore what's going on with the metadata.

Regards,
Kent

[leicray]

Hi Kent,

I might find the time to do this tomorrow. Unfortunately, I did not keep copies of the original FLAC files, so I will have to try to reproduce the issue.

Just to make things more complicated, I decided to upgrade from version 4 to version 6 of moOde and the cover art problem magically disappeared, even for those albums that had not yet been through the FLAC > ALAC > FLAC conversion cure. I did keep the microSD card for version 4, so I can boot my Pi into that version to identify which tracks have problems with the cover art.

I'll report back tomorrow, hopefully.

Regards,

Raymond