Picard doesn't tag FLAC files properly

I’ve been trying to tag my FLAC files for a while now, and all of them have things like years, track numbers and titles missing. I unchecked read-only to allow Picard to save the tags on track in the first place, but whenever I go to properties, I see it checked again.

If Picard cannot write to a file you will see a red stop sign as the file icon after saving. Does this happen? In this case make sure the read only is not set for both the file you try to save and the folder it is located in.

If Picard does not show an error the issue is something else, e.g. you might have “Save tags to files” turned off.

1 Like

Save tags is checked.
When I first tried to tag the file, it did show up with the red sign. So I unchecked read only, and pressed save. This is when it put some things, but others, like titles and numbers (as above) were randomly missing. When I looked at its properties again, read only was checked. On unchecking it, clicking apply, and looking at the properties again, I find that read-only is again checked.

You’re looking the attributes of the parent folder and they’re meaningless in Windows. Double check the files if you need to be sure.

Also, use something… anything other than Windows Explorer for checking your FLAC tags.

1 Like

Groove music doesn’t recognize them

Groove is probably using the same underlying code as Explorer so it can not be relied upon. And just like WMP, it has no respect for user’s files and will happily overwrite tags with its own junk from its own online sources without even prompting you.To double check this, simply enable the option in Windows Explorer to show all hidden + system files and if you find the folder littered with tiny little jpg files, that means Groove has been busy downloading complete and utter poop!!

FWIW, I’m a Windows user and couldn’t ever see myself using anything else but there are some things it is just terrible at. Managing music +metadata is one of them.

5 Likes

Another Windoze user here - and the horrendous inability to do proper tagging continues in Win10. It may have been an “upgrade” to add FLAC support in Win10 - but it is as bad as MP3 was in Win7… :frowning:

MP3TAG.de is my goto program for working alongside Picard. (Look for the Extended Tags button to get a full view of everything Picard has added to a track.)

And ANY media player that isn’t Groove is an improvement. Foobar2000, VLC even Winamp has reappeared from the grave! I mainly use KODI but that can be an overkill for many people who don’t need a library.

Even Microsoft have admitted that Groove has failed when they binned the subscriptions and gave Spotify subscriptions to the three people who had signed up. Run away from it. Run a long long way away from it if you want to keep your sanity.

(Note I have not said the words “iTunes” at any stage… that is not a music player, that is shopping software that wouldn’t know what a FLAC was)

1 Like

I was having the same issue until I set my tagging options like this. All my files are flac and it works for me on windows 10. Flac files don’t like ID3 tags they get along with vorbis tags.

4 Likes

FLAC - FAQ says:

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.

Picard’s option remove_id3_from_flac is set to False (disabled) by default (picard/picard/ui/options/tags.py at release-2.1.0 · metabrainz/picard · GitHub).

May be it would make sense to set it to True by default if most users expect ID3 tags to not be written to FLAC files.

@outsidecontext : what do you think ?

1 Like

Not sure. On the one hand I think it is bad practice to have a default option that removes data from files. In the other hand people expect that tags get updated, and outdated ID3 tags will cause trouble like here. Also not sure how common FLAC files with ID3 tags actually are and if there is a real use for them. At least I never saw a request by someone wanting to be able to write ID3 tags to FLAC.

Since the official FLAC FAQ says:

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.

I’d tend to think it is safer to not write ID3 tags in FLAC files by default, but i agree about “it is bad practice to have a default option that removes data from files”.
On first FLAC ID3 tags (re-)write attempt, we may show a dialog explaining pros & cons of this setting and asking the user what he wants to do (including not showing the dialog again).

Perhaps first it’d be interesting to know which common apps have issues with ID3 tags in FLAC files or not. On my side i never disabled this option (which is in Picard since 12 years), and never had any issue with it (but i’m using only linux and open source apps).

1 Like

Having the option to preserve timestamps enabled is a pretty bad idea and it could cause problems exactly like the OP is having. Parsing media files for tags is an expensive operation so obviously most players will build a cache on the first run to enable faster browsing/searching etc. If tags get modified but the timestamp remains the same, then how is the player supposed to know without parsing every file again ( yes, you could check sizes, hashes etc but why abuse last modified in this way???)

Getting timestamps is an amazingly cheap operation and that’s why conventions like this exist in the first place.

It’s not to be used as some sort of reference of when you’d like to think you first acquired/updated the files.

The file HAS BEEN modified so don’t pretend it hasn’t. IMHO, all tag writing applications should respect the convention without letting users override them.

2 Likes

I keep that checked because after picard is finished it moves the files to their final resting place which is then automatically uploaded to google music servers. If I update the local copy with new meta data and change the timestamp the up-loader will send as a new file then my cloud database gets filled with duplicates. Fixed the image so that won’t be confused as a setting for the tags themselves.

1 Like

@marc2k3 some of us use the File Modified dates to keep track of when the files were ripped from CD. To us the music in the file is the important part. Updating the metadata is not adjusting the major part of the file.

It is a choice many of us use, so it is good to see it available.

I believe I covered that exact point in my original post :stuck_out_tongue:

Anyway, I will concede there is nothing worse than being told by others what you should and shouldn’t do with your own files… so carry on!!

1 Like

^^^ This… in large bucket loads. Hehehe

You are, of course, correct. But I am also rightly wrong and there are plenty of us wrong-uns round 'ere. :wink:
This whole forum is full of mad people using tools in the ways they shouldn’t be. The poor Picard writers get driven mad trying to fit into all of our different “standard” ways of doing things.

If I want to stir my tea with a fork then I will do just exactly that :stuck_out_tongue:

It is very noticeable that standards like FLAC really get developed and expanded within forums like this. Where people are actually using these standards. Then, eventually the official documents catch up with common usage.

I get amazed at the number of different systems that something like Picard has to cater for. :smiley:

Just hope someone adds @therealdero’s Tag Settings for Win10 image to the help files somewhere. That will be very useful for the Win10 brigade when trying to work out why they got borked tags.

I am sure I used to have a reason for needing ID3 tags in my FLACs at some point in the past… just like I used to have a player that needed ID3v1 tags.

Something I’d love to see Added to Picard is some for of “Tagging Profile”. Something that lets different combinations of Tag Settings to be used depending on the target device\usage.

1 Like

I tried this fix out and it works great in Windows 10 Pro 1809. You have to have dBpoweramp installed for it to work since it uses their property handlers. But you can install the trial version it changes to the free version after the trial. When you hover over a file a window with all the information appears.

Screenshots

2 Likes