Albums without embedded albumart always show Modified and Complete

Hello,

I don’t want to save embedded albumart into every track (just saving them as cover.jpg) but this results in the album flagged as modified and complete everytime I open it to edit the metadata.

As soon as I embed the albumart again it registers as unchanged and complete.

I cannot find a way to ignore ‘missing’ albumart, so i’m wondering if this is a bug or expected behaviour?

Maybe i’ll just have to re-embed my albumart, but was hoping not to!

Many thanks
James

Probably this known bug: [PICARD-1001] Cover art changes are indicated even if there's no change after loading a release - MetaBrainz JIRA

Do you have to re-load your already tagged albums? You could avoid this by tagging the album + adding the cover art file in the first pass, then move into your tagged music folder. And when you update your tagged music folder uncheck ‘add cover art’ completely, then this it will only show a change if a tag has been updated.

Not ideal sorry, but a possible workaround!

1 Like

Think you are correct with that known bug - thanks!

Will give that workaround a go - however, more often than not I am upgrading the album art (when reloading already tagged) so would I need to recheck that setting to save new art?

Unfortunately yes, currently you would have to do another pass for album art, and you wouldn’t know if it’s being replaced or not (as it will always say ‘modified’).

Okay thanks - I think I will re-embed album art for now. Thanks for the advice/help

On a slightly unrelated note, I also seem to have loads of tracks that don’t match Length data from MB - is that a metadata field or is Picard literally checking the actual track length of my files?

Many albums will have reissues with different length files. And different again on compilations.

Are your tracks from exact known CD rips? Or “best matches” due to being from other sources?

Mostly cd rips but some are probably a mix of both to be fair, which might explain it - thanks!

The length comes from the files. I think for MP4 files it comes from some kind of metadata structure inside the files, but usually it is calculated from the sample rate. It can be an estimate in some cases (e.g. for raw .aac and .ac3 files, guessed from bitrate).

1 Like

You’ll see that a CD rip should be bang on. Assuming the correct DiscID is attached to the release.

Sometimes a different or no DiscID is on the Release. In these cases you can fix this with your own CD. Put the CD in the drive and click on Picard’s “Lookup CD” and then “Submit DiscID” to attach it to he Release. Now you should be able to make sure the Release on the line has the correct track lengths.

If you are adding discIDs, be careful to select the actual matching one. A CD that has been pressed for a couple of decades tends to go through many different variations. Make sure you have a correct barcode \ country \ catno match in those cases.

Tracks on albums from “other” sources can often be out for all kinds of reasons.

3 Likes

Great info thanks. Also forgot I upgraded lots of my CD rips to flac from bandcamp & qobuz so they might not be proper matches anymore

1 Like

Yeah, that would do it. Technically you now have the “digital media” release instead where you would find the exact time match. Though I follow the logic of still tagging that as your CD. :slight_smile:

1 Like