Thank you for your donation!


Messy Cover Art in MoodeAudio 4.3
#11
@BlackSmile, I'm not seeing any issues on my end, however I'm using code that has been modified for the upcoming moOde 4.3 in-place update. I tested with Cover search priority = Embedded cover and again with it = Cover image file.

         

The update includes a fix for the bug mentioned in post #9 above as well as a super nice enhancement called "cover hash" which eliminates the annoying cover image reload that occurs when changing tracks within an album :-)

-Tim
Enjoy the Music!
http://moodeaudio.org | http://twitter.com/MoodeAudio | http://github.com/moodeaudio
Reply
#12
OK so it's maybe fixed when i'll update. Just to add that my problem appear on the local ui display (7" display) and on a web browser too.
I repeat maybe but is it normal that when I go in customize : cover search priority is empty (neither embedded or image file) ?
thx
Rasptouch case with RPI3 + I2C 16x2 screen and IR port
Audiophonics I-Sabre V2.1 DAC ES9023 TCXO
Reply
#13
Not normal. Try clearing the Browser cache.

The local UI browser cache can be cleared via the button in System config.
Enjoy the Music!
http://moodeaudio.org | http://twitter.com/MoodeAudio | http://github.com/moodeaudio
Reply
#14
(10-12-2018, 08:45 PM)Tim Curtis Wrote: Not normal. Try clearing the Browser cache.

The local UI browser cache can be cleared via the button in System config.

I allready try many times but no result. Could it have something to do with permission or the fact that I squash the FS ?
Rasptouch case with RPI3 + I2C 16x2 screen and IR port
Audiophonics I-Sabre V2.1 DAC ES9023 TCXO
Reply
#15
    Hello Listeners to MoodeAudio!

This is what I did:
The music files are on an USB stick without folders or directories.
Each music file has embedded cover art, done with the software MP3TAG.
Not all files have info on the tag "ALBUM"
Once MoodeAudio "sees" the USB stick, I click on the name "USB" and the name of the stick appears, I click on the ICON (before the name) and choose Clear/Play.

Playing the music files:
Some music files appear with cover art, others don't.
When there is a change to another album, it switches to coverart and next album without cover art, and so on.

Before I discovered MoodeAudio I used Volumio and Rune.
I read in Volumio forum that cover art is not used anymore.
I took an old image of Rune from 2016 and from the above mentioned stick all cover art is displaye correctly.
In the past I used MoodeAudio 3.8 and all worked well.

Screenshot: all cover art is from the last item on the stick.
The first item on the stick is from The Kinks, and it has the cover art from the stereo test, which music file is in the Moode image on the SD card!

Anyone who has an idea, please help.

Dig-It
Reply
#16
(10-27-2018, 07:18 PM)Dig-It Wrote: Hello Listeners to MoodeAudio!

This is what I did:
The music files are on an USB stick without folders or directories.
Each music file has embedded cover art, done with the software MP3TAG.
Not all files have info on the tag "ALBUM"
Once MoodeAudio "sees" the USB stick, I click on the name "USB" and the name of the stick appears, I click on the ICON (before the name) and choose Clear/Play.

Playing the music files:
Some music files appear with cover art, others don't.
When there is a change to another album, it switches to coverart and next album without cover art, and so on.

Before I discovered MoodeAudio I used Volumio and Rune.
I read in Volumio forum that cover art is not used anymore.
I took an old image of Rune from 2016 and from the above mentioned stick all cover art is displaye correctly.
In the past I used MoodeAudio 3.8 and all worked well.

Screenshot: all cover art is from the last item on the stick.
The first item on the stick is from The Kinks, and it has the cover art from the stereo test, which music file is in the Moode image on the SD card!

Anyone who has an idea, please help.

Dig-It

Off the top of my head, no idea, but I'll make the same offer Tim made. Make the files available to me somehow and I'll see if I can come up with something. I've been slowly amassing a collection of utilities which examine mp3 (and other encodings) files and their metadata.

Assuming the files are not too voluminous, you could zip up the entire directory and put the result in a private folder on Dropbox, Google Drive, or some other file-sharing medium and send me the download link via a Private Message on this forum. If that's too much, then zip up just the first half-dozen or so files. Be sure you include both files whose cover art appears and files whose cover art doesn't appear.

Regards,
Kent
Reply
#17
(10-27-2018, 07:18 PM)Dig-It Wrote: Hello Listeners to MoodeAudio!

This is what I did:
The music files are on an USB stick without folders or directories.
Each music file has embedded cover art, done with the software MP3TAG.
Not all files have info on the tag "ALBUM"
Once MoodeAudio "sees" the USB stick, I click on the name "USB" and the name of the stick appears, I click on the ICON (before the name) and choose Clear/Play.

Playing the music files:
Some music files appear with cover art, others don't.
When there is a change to another album, it switches to coverart and next album without cover art, and so on.

Before I discovered MoodeAudio I used Volumio and Rune.
I read in Volumio forum that cover art is not used anymore.
I took an old image of Rune from 2016 and from the above mentioned stick all cover art is displaye correctly.
In the past I used MoodeAudio 3.8 and all worked well.

Screenshot: all cover art is from the last item on the stick.
The first item on the stick is from The Kinks, and it has the cover art from the stereo test, which music file is in the Moode image on the SD card!

Anyone who has an idea, please help.

Dig-It

The configuration you describe
- The music files are on an USB stick without folders or directories.
- Not all files have info on the tag "ALBUM"

will not work well with moOde's Library list and Album Cover panels. Refer back to post #2
http://moodeaudio.org/forum/showthread.p...06#pid4406

However, if your files have embedded covers and they do not appear in the Playback panel then feel free to zip up a couple of the files and email me a download link. I'll see if I can repro your issue.

EDIT TO ADD: also send download link to @TheOldPresbyope so the files can be analyzed :-)
Enjoy the Music!
http://moodeaudio.org | http://twitter.com/MoodeAudio | http://github.com/moodeaudio
Reply
#18
(10-27-2018, 07:38 PM)Tim Curtis Wrote: ...
However, if your files have embedded covers and they do not appear in the Playback panel then feel free to zip up a couple of the files and email me a download link. I'll see if I can repro your issue.

EDIT TO ADD: also send download link to @TheOldPresbyope so the files can be analyzed :-)

I've received a sampling of .flac files from @Dig-It

At first blush, all 40 files are syntactically correct with regard to their METADATA (in the FLAC sense) blocks, specifically the VORBIS_COMMENT (metadata in the ID3 sense) and PICTURE (e.g., embedded coverart) block types. 

My Linux file browser displays the images of all 40 files as thumbnails in a directory listing.

However, I can repro Dig-it's report that some of these embedded covers do not display in the moOde Playback panel. 

In the successful case, moOde returns an image link such as "http://moode/coverart.php/USB%2FKAR04%2FexamFiles%2FJames%20Bay%20-%20Let%20It%20Go.flac"

For all unsuccessful cases, moOde returns "http://moode/images/default-cover-v6.svg". 

I don't see anything interesting in moode.log even with debug logging enabled.

I'm in the process of identifying all the affected tracks so I can go back and look for clues in their metadata that would set them apart compared to the others. I may start probing coverart.php as well.

Regards,
Kent
Reply
#19
A followup:

I don't know how this disrupts coverart.php (more precisely, the Zend routine it calls) but I have a signature for *all* the .flac tracks whose embedded coverart does not display in the Playback panel.
  • metaflac reports they contain a FLAC METADATA block type SEEKTABLE which in each case occurs before the VORBIS_COMMENT and PICTURE type blocks
  • exiftool reports:   Encoded by: Exact Audio Copy   (Burst Mode)
  • exiftool reports:  Encoder Settings : FLAC.EXE -6 -V -T "ARTIST=..." -T "TITLE=..." ... etc.
*None* of the tracks whose embedded coverart do display in the Playback panel contain any of these. No SEEKTABLE is found by metaflac; neither "Encoded by" nor "Encoder Settings" is reported by exiftool.


EDIT TO ADD: turning on moOde debug logging, I see lines like

Code:
20181029 111925 readMpdResponse(): success $resp[0]=(file: USB/KAR04/examFiles/In-Grid - Tu Es Foutu.flac)
20181029 111925 enhanceMetadata(): coverurl: (/coverart.php/USB%2FKAR04%2FexamFiles%2FIn-Grid%20-%20Tu%20Es%20Foutu.flac)


In all cases, the URL contained in the coverurl variable references the correct track.

In the successful case, the image generated via that URL is what the Playback panel displays. In the unsuccessful case, the Playback panel instead displays the default svg image.

Regards,
Kent
Reply
#20
@Dig-It

It appears the root cause of our difficulties is that whatever tool was used to manipulate the metadata on the misbehaving .flac tracks encoded the wrong "magic number" in the first 4 bytes of the files.

The first 4 bytes of a FLAC file are specified to be Hex 66 4C 61 43 which is  "fLaC" in ASCII.

For the files I previously identified as having odd properties, the first 4 bytes are Hex 49 44 33 03 which is "ID3^C" in ASII (where ^C represents the ASCII CTRL-C character). That "ID3" string is the specified header for an MP3 file with prepended ID3V2 metadata.

For some reason, the Xiph.org Audio metaflac tool I used doesn't flag this even though it is a tool from the very people who maintain the FLAC specification. Tim caught it in his own analysis (Yay, Tim!). 

Using the Linux file command is an easy way to catch this. Where possible, the first part of its report is based on magic-number analysis.

For your FLAC files with the specified header, it reports "FLAC audio bitstream data..."

For what I'll call your "ID3" files, it reports "Audio file with ID3 version 2.3.0, contains: FLAC audio bitstream data..."

My position is that a FLAC-encoded file isn't a FLAC file if it doesn't have the specified header even if some software apparently ignores the contradiction. To me, it's perfectly proper for the Zend framework to enforce the specification.

I'm not sure there's a simple way to repair the files. My first attempt using dd to overwrite the first 4 bytes of one seemed to succeed syntactically but the resulting file wasn't recognized by the audio tools. I'll look into this further if I can find the time but no promises.

Regards,
Kent
Reply


Forum Jump: