Flac errors in system info, moode 5

[CallMeMike]

Hi Kent, managed to install metaflac on my pi............snip........... I have removed all tags, embedded art and folder.jpg from the Black Sabbath album, leaving just the file names, but the errors are still showing.

Looks like the only answer to this problem is to get a fresh copy.

.... a fresh copy or (cheaper) re-convert the offendng flac file using your choice audio file converter (do not worry, the quality of the file will NOT be altered)... after the conversion just copy back in the same folder the corresponding 'front' or 'cover' or folder' JPG file. In case you don't have a audio file converter application available get some inspiration from here: AudioConverte_freeware

I personally use https://xrecode.com/ ... It's not freeware but it has a grace time (30 days I believe) allowing you to decide whether you want to purchase a licence. After un-installing and re-installing it several times (cheapskate  ) I gave in and I've purchased a licence...

[kit1cat]

Thanks for your suggestion mike, I will give it ago.

[kit1cat]

Can confirm, converting the files to wave then back to flac solved the problem.

[TheOldPresbyope]

So, @kit1cat sent me a couple FLAC files to look at.

Confusing because metaflac --list didn't complain about them while flac -t complained that their MD5 signature (aka fingerprint, aka checksum) is unset.  The latter is true but not relevant to the coverart problem. 

Had to stare at the output for a while.

Here's the first part of the metaflac --list output for one file:

Code:

METADATA block #0
 type: 0 (STREAMINFO)
 is last: false
 length: 34
 minimum blocksize: 4096 samples
 maximum blocksize: 4096 samples
 minimum framesize: 530 bytes
 maximum framesize: 12404 bytes
 sample_rate: 44100 Hz
 channels: 2
 bits-per-sample: 16
 total samples: 7397376
 MD5 signature: 00000000000000000000000000000000
METADATA block #1
 type: 2 (APPLICATION)
 is last: false
 length: 44
 application ID: 46696361
 data contents:
Medieval CUE Splitter (www.medieval.it)
 type: 3 (SEEKTABLE)
 is last: false
 length: 666
 seek points: 37
   point 0: sample_number=0, stream_offset=0, frame_samples=4096
   point 1: sample_number=204800, stream_offset=445006, frame_samples=4096
...

As you can see, the MD5 signature is zeroed out. This does not seem to bother many decoders. The file plays in all my players (including MPD) for example.

But look carefully at the two lines starting with "Medieval...." What one should see is three lines

Code:

Medieval CUE Splitter (www.medieval.it)
METADATA block #2
 type: 3 (SEEKTABLE)

Turns out the proper header for block #2 is in the file but apparently the application Medieval CUE Splitter failed to write a proper preceding block (right again, Tim!). I didn't bother counting bytes to see what it did. Why this doesn't discombobulate any tools I have on hand to deal with FLAC file metadata and validation I don't know. Clearly, the Zend_Media_Flac routine used in moOde gets lost, although it has no problem finding and parsing the following VORBIS_COMMENT block (to get track title, artist, etc).

I was able to "fix" the files in two licks (fair warning, I'm overwriting files here):

Code:

pi@moode:/mnt/SDCARD/test2 $ sudo flac --best -f *.flac

flac 1.3.2
Copyright (C) 2000-2009  Josh Coalson, 2011-2016  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

02-paranoid.flac: wrote 19291177 bytes, ratio=1.000
03-planet-caravan.flac: wrote 19869663 bytes, ratio=0.995

pi@moode:/mnt/SDCARD/test2 $ sudo metaflac --remove --block-type=APPLICATION *.flac

The first command generated the MD5 signature while fiddling with compression but not transcoding the stream data. (not relevant to the coverart issue.)

The second command removed the offending APPLICATION block and renumbered the remaining blocks.

Repeating the metaflac --list command on the result for the first file

Code:

METADATA block #0
 type: 0 (STREAMINFO)
 is last: false
 length: 34
 minimum blocksize: 4096 samples
 maximum blocksize: 4096 samples
 minimum framesize: 530 bytes
 maximum framesize: 12406 bytes
 sample_rate: 44100 Hz
 channels: 2
 bits-per-sample: 16
 total samples: 7397376
 MD5 signature: 80e406c584277203acb7e993d9a5e26c
METADATA block #1
 type: 3 (SEEKTABLE)
 is last: false
 length: 666
 seek points: 37
   point 0: sample_number=0, stream_offset=0, frame_samples=4096
   point 1: sample_number=204800, stream_offset=445014, frame_samples=4096

Odd that metaflac is able successfully to remove an apparently malformed block but there you are.

A screenshot of my moOde r5.0 playing one of the fixed tracks.



Live long and prosper.

Regards,
Kent

[kit1cat]

Well done Kent, glad you sorted it. You have a true Valcun brain. ?

[jonners]

Well done Kent, glad you sorted it. You have a true Valcun brain. ?

That's even better than a Vulcan brain isn't it?

[kit1cat]

jonners

Well done Kent, glad you sorted it. You have a true Valcun brain. ?

That's even better than a Vulcan brain isn't it?

It’s been a long day. ?

[TheOldPresbyope]

Well, whether Valcun or Vulcan, I continued to be nagged by the apparent evidence that the metadata block of type APPLICATION was malformed and yet metaflac was able to remove it and leave a clean file. That seemed, er, "illogical, Captain".

I read the metaflac documentation more carefully and discovered one can force it to hexdump the application block's data contents rather than list it as text. When I do that with @kit1cat's files, the missing METADATA block line reappears. What seemed a 'smoking gun' before may have been nothing more than non-printing, binary bytes disrupting the output formatting.

I then went looking through all the FLAC files in my possession to see if any contained an application block. I found a whole album (HDtracks 2017 Hi-Res Sampler) which I'd downloaded at some point but never added to my NAS. All 15 track files contain full metadata including picture (coverart) and application blocks. Running metaflac --list --application-data-format=hexdump on these files properly lists all the blocks.

I added them to a directory on moOde's SDcard. I didn't get errors in moode.log when MPD scanned these files but I also don't get the coverart displayed in the playback panel.

If I then remove the application blocks from the files, as I described in my prior post, and update, the coverart does display.

At this point, I have to suspect the treatment of the application-block element by Zend.

@Tim Curtis - any thoughts about how best to go about tracing through the Zend_Media_Flac routines? I've read through all the FLAC-related code but PHP isn't my cup of tea. Just stick in test-probes like I see you've added in the past?

I'm tempted to write my own Python file-checker code to count bytes based on the xiph.org spec to confirm the files I have are legitimate as well as to make sure I understand the FLAC file structure well enough to critique the Zend code.

Regards,
Kent

[Tim Curtis]

You would have to contact the Zend dev if you think their code is not obeying the FLAC standard.

-Tim