[SOLVED] Incomplete ArtWork Scan

[TheOldPresbyope]

@Miss Sissy Princess 
The FLAC specification looks quite complete to my eyes.
https://xiph.org/flac/format.html
https://xiph.org/vorbis/doc/v-comment.html

FLAC codec and associated utilities from xiph.org are IME the most widely used in Linux audio precisely because of their high quality implementations, efficient algorithms and well defined specifications.

ALAC is typically only found in collections where iTunes is or was used. Even after Apple released the ALAC specification back in 2011 as Open Source the adoption rate has been almost nil in the Linux audio community because FLAC has been in use since 2001 and was already a proven winner with high quality implementations, speed, efficiency and metadata support.

Oddly Apple still does not support FLAC in the iTunes / Apple Music eco system while most Linux audio players support a wide variety of formats including ALAC.

Just a quick update: I went through my collection and found 1%-2% missing art work, mostly in AIFF files, even if most were fine. After the conversion, I only have a handful of issues out of hundreds of albums, and all for different reasons that I am solving now

It sounds like the following tip may no longer be relevant for you, but I found that converting your .m4a files to .flac files using ffmpeg worked well. 

The "Audio info" popup in moOde is reporting the converted files are encoded as 24 bit/44.1 kHz FLAC. They are playing and coverart is being displayed in the Library and Playback views.

The conversion is easy-peasy. For example

Code:

pi@moode:~ $ ffmpeg -i '01 Dance Yrself Clean.m4a' '01 Dance Yrself Clean.flac'

where the -i option indicates the next file name is the input file and the format of the resulting output file is inferred from its extension (.flac in this case). Note that the output file name can be whatever you like. Consult the ffmpeg man page for more information.

I notice that in the middle of the diagnostics printed during the conversion process, ffmpeg reports

Code:

[swscaler @ 0x77c420] deprecated pixel format used, make sure you did set range correctly
[swscaler @ 0x77c420] No accelerated colorspace conversion found from yuv420p to rgb24.
[flac @ 0x75c2c0] Frame rate very high for a muxer not efficiently supporting it.
Please consider specifying a lower framerate, a different muxer or -vsync 2
[flac @ 0x75d3a0] encoding as 24 bits-per-sample

but I don't know if this information is relevant to the issue at hand.

Okay, coffee break is over. Gotta go move boxes (anybody remember Monty Python's early sketch "The Society of Putting Things on Top of Other Things"?).

Regards,
Kent

[Miss Sissy Princess]

@Miss Sissy Princess 
The FLAC specification looks quite complete to my eyes.
https://xiph.org/flac/format.html
https://xiph.org/vorbis/doc/v-comment.html

FLAC codec and associated utilities from xiph.org are IME the most widely used in Linux audio precisely because of their high quality implementations, efficient algorithms and well defined specifications.

This isn't a specification; it's a vague suggestion rather than a set of requirements:

Field names

Below is a proposed, minimal list of standard field names with a description of intended use. No single or group of field names is mandatory; a comment header may contain one, all or none of the names in this list.

...

• Individual 'vendors' may use non-standard field names within reason. The proper use of comment fields should be clear through context at this point. Abuse will be discouraged.
  
  
• There is no vendor-specific prefix to 'nonstandard' field names. Vendors should make some effort to avoid arbitrarily polluting the common namespace. We will generally collect the more useful tags here to help with standardization.
  
  
• Field names are not required to be unique (occur once) within a comment header. As an example, assume a track was recorded by three well know artists; the following is permissible, and encouraged:
               ARTIST=Dizzy Gillespie
               ARTIST=Sonny Rollins
               ARTIST=Sonny Stitt  
  

That quote from the spec confirms my prior statement:  "One of the problems with FLAC is that its tagging ("FLAC tags" are also called "Vorbis comments") is so loosey-goosey, with no set of standard, minimum, or required tags."  

I spent much of my career working to, and writing, engineering specs.  Specifications have words like "shall" and "must."  They aren't proposed lists and suggestions that no one is required to follow.  They don't 'discourage abuse or arbitrarily polluting' file formats; they define file formats.

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.

This is nuts!  You can have a FLAC files that plays fine in the "reference decoder" and that fails to play in decoders that are written to comply with the FLAC documentation.  People can randomly shove in ID3 tags and that's fine and dandy? 

Oddly Apple still does not support FLAC in the iTunes / Apple Music eco system while most Linux audio players support a wide variety of formats including ALAC.

Some years ago I studied up on the FLAC tagging mess after running into problems with FLAC files that would work on some players and fail on others.  If I were Apple, I wouldn't want to deal with FLAC either -- even though it has slightly more efficient compression than ALAC and incorporates ED&C.

How would you suggest the OP "fix" his .m4a files?

By determining what is wrong with them and bringing them into compliance with the specifications.  I have the feeling if the problem was with his FLAC files, you wouldn't be telling him to just convert them all to .m4a ALAC files because it's hopeless to try to repair corrupted FLAC files.

[Tim Curtis]

I completely disagree.

You can choose to go Apple ALAC or whatever but 20 years and still going strong the FLAC format has proven itself to be a superior lossless audio format.

-Tim

[Miss Sissy Princess]

I completely disagree.

Then we'll just have to agree to disagree about what constitutes a specification.  

This is what "Spoon" had to say about FLAC's tagging on hydrogenaud.io:

That is just it, when there is no official standard the there are sub-standards. Do you know there are 3 ways of storing album artist? it is sad because (although Ogg Vorbis is not going anywhere), FLAC has the potential to become the standard lossless audio codec, but not if there are such blatant incompatibilities. Its main competitors: ALAC and WMA Lossless have no tagging issues.

Spoon is the lead developer of dBpowerAMP Music Converter.  

You can choose to go Apple ALAC or whatever but 20 years and still going strong the FLAC format has proven itself to be a superior lossless audio format.

MP3 remains the most popular lossy format more than 30 years after its creation. I don't see that as evidence that it is superior to AAC, Opus, and Vorbis.    

This isn't religion to me.  Every format has pluses and minuses.  FLAC provides superior compression as well as ED&C.  ALAC has official standards for tagging that are clear and relatively unambiguous.  Give me the FLAC codec with the Apple-defined ALAC tagging and I'd be quite happy. 

[TheOldPresbyope]

Turning this thread into a referendum about FLAC and in particular its representation of audio metadata has done nothing to solve the OP's problem.

The original files are legal MPEG4 containers with audio, metadata, and embedded coverart. However they also contain one or more additional objects which apparently do not conform to Apple's specialization of MPEG4 containers for its M4A format. This in turn apparently confuses the PHP library used in moOde to handle media files. Or something like that.

I now have two solutions to the OP's issue. Either can be executed from the command line in moOde.

1) as I showed before, use ffmpeg to convert the suspect M4A files to FLAC. The AAC LC audio object is transcoded to FLAC, the audio metadata and coverart are transfered in the form specified for FLAC. The additional objects in the container are ignored.

2) as I have since found, one can also use ffmpeg to copy the suspect M4A file to a new M4A file. As before, the additional objects in the source container are ignored.

Example

Code:

pi@moode:~ $ file '01 Dance Yrself Clean.m4a'
01 Dance Yrself Clean.m4a: ISO Media, MP4 v2 [ISO 14496-14]

pi@moode:~ $ ffmpeg -i '01 Dance Yrself Clean.m4a' -c copy 01-fixed.m4a
...

pi@moode:~ $ file 01-fixed.m4a
01-fixed.m4a: ISO Media, Apple iTunes ALAC/AAC-LC (.M4A) Audio

and the resulting track properly plays and displays in moOde just as did the FLAC version I created earlier. Take your pick.

As for the use of metadata in different audio file formats, I find the Picard Tag Mapping Table to be very useful. It is a "list of specific metadata tags defined by MusicBrainz and standard tags, for ID3v2, Vorbis, APEv2, and iTunes MP4."

Regards,
Kent

[Nautilus]

Turning this thread into a referendum about FLAC and in particular its representation of audio metadata has done nothing to solve the OP's problem.

The original files are legal MPEG4 containers with audio, metadata, and embedded coverart. However they also contain one or more additional objects which apparently do not conform to Apple's specialization of MPEG4 containers for its M4A format. This in turn apparently confuses the PHP library used in moOde to handle media files. Or something like that.

I now have two solutions to the OP's issue. Either can be executed from the command line in moOde.

1) as I showed before, use ffmpeg to convert the suspect M4A files to FLAC. The AAC LC audio object is transcoded to FLAC, the audio metadata and coverart are transfered in the form specified for FLAC. The additional objects in the container are ignored.

2) as I have since found, one can also use ffmpeg to copy the suspect M4A file to a new M4A file. As before, the additional objects in the source container are ignored.

Example

Code:

pi@moode:~ $ file '01 Dance Yrself Clean.m4a'
01 Dance Yrself Clean.m4a: ISO Media, MP4 v2 [ISO 14496-14]

pi@moode:~ $ ffmpeg -i '01 Dance Yrself Clean.m4a' -c copy 01-fixed.m4a
...

pi@moode:~ $ file 01-fixed.m4a
01-fixed.m4a: ISO Media, Apple iTunes ALAC/AAC-LC (.M4A) Audio

and the resulting track properly plays and displays in moOde just as did the FLAC version I created earlier. Take your pick.

As for the use of metadata in different audio file formats, I find the Picard Tag Mapping Table to be very useful. It is a "list of specific metadata tags defined by MusicBrainz and standard tags, for ID3v2, Vorbis, APEv2, and iTunes MP4."

Regards,
Kent

Many thanks Kent, not only for your useful advise but also for trying to keep the conversation on track to help the OP, i.e. me!

The problem has been solved, in my case transcoding using XLD, and then using Metadatics. I want to thank everyone that has spent time in reading this and sending advise: this is clearly a healthy and lively community

I was trying to find how to change the subject from "PROBLEM" to "SOLVED", but can not find how to do it, so just let me know.

Thanks to everyone again!

[Tim Curtis]

Just edit your original post #1. There is a dropdown next to the title.

[Nautilus]

Just edit your original post #1. There is a dropdown next to the title.

Done! Thank you again!!

[Woodroww]

FLAC has the potential to become the standard lossless audio codec...

I thiink it already is.