Are covers/artworks:
- stored as image in the *.flac files?
- not store in the file but use a reference to a file?
- does it depend on the tagging program?
Either one you want.
In File Positives
- Tends to be more compatible with some applications.
- Much more portable and convenient, especially with singles if you store them in different directories with each other and occasionally move them to different directories.
- It's cleaner in the directories where the files themselves are stored.
In File Negatives
- Very large images may not fit if you embed a ton of different ones (disc art, front and back covers, booklets).
- Takes more space with whole albums.
Linked Positives
- Saves space when it comes to whole albums.
- Can store a ton of different images of stuff at larger file sizes than what most files will have padding for.
Linked Negatives
- Not very portable, especially with singles if you store them in different directories with each other and occasionally move them to different directories.
- Messier in directories that store the files themselves.
Not to forget: Some media players are happy to search in the same directory as the media file.
Thank you.
In case somebody else is looking for answers, here are the fact that lead to my original question, and the answers I found so far:
- CUERipper embedded album art in files. There is an options for that in "Options" but I had let it set on true. Turning to false includes albums art in folder but not in files.
- CUERipper also included the covers avec "folder.jpg" in each disc folder.
- I added some covers using Mp3Tag.
- Foobar2000 seems to look in priority for file-embedded pictures, then folder images.
- For some files I changed with Mp3Tag, Foobar2000 didn’t seem to see the changes right away. Made me think there some caching going on? Not sure. Also these files ended up with multiple embedded image.
- The most commonly found command line to remove pictures actually disabled the file-embedded pictures not remove the picture bytes from the file (filesize was not changing)
That line looked like metaflac.exe --preserve-modtime --dont-use-padding --remove-tag=PICTURE filename.flac
I also tried, based on some source I don’t remember:
metaflac.exe --preserve-modtime --dont-use-padding --remove-tag=Picture --remove-tag=PictureType --remove-tag=PictureMIMEType --remove-tag=PictureDescription --remove-tag=PictureWidth --remove-tag=PictureHeight --remove-tag=PictureBitsPerPixel --remove-tag=PictureIndexedColors --remove-tag=PictureLength filename.flac
- The line that, in the end, succeeded at actually removing pictures from the files was
metaflac.exe --preserve-modtime --dont-use-padding --remove --block-type=PICTURE *.flac
- In some quick tests:
- Performing the -remove-tag=Picture --remove-tag=PictureType ... command line does not remove any extra byte compared to the --remove --block-type=PICTURE ... line. File size are strictly equals.
- Files "Embed album art" = true and where --remove --block-type=PICTURE ... command line was applied are a few kilobytes smaller than files just ripped with "Embed album art" = false. Which makes me wonder what resulting the difference inside the file is, but I think I can live not knowing this.
Foobar2000 seems to look in priority for file-embedded pictures, then folder images.
There's a setting in foobar2000 Advanced preferences: Display -> Album art -> Embedded vs external.
For some files I changed with Mp3Tag, Foobar2000 didn’t seem to see the changes right away. Made me think there some caching going on?
Don't set option "preserve modification time", foobar2000 relies on this info.
Positive for using an image file in the same directory:
- Artwork can be easily updated later with a better quality (accurately cropped, square) without using special software or modifying audio files.
- You can tell that artwork is present, and look at it in full size using any image viewer.
few kilobytes smaller than files just ripped with "Embed album art" = false. Which makes me wonder what resulting the difference inside the file is,
New files without artwork include a small amout of padding to allow adding more metadata tags without rewritting the entire file to make room. The metaflac command line removed all padding.
Thank you.
Don't set option "preserve modification time", foobar2000 relies on this info.
Why? Do you mean it uses modification date for some caching purpose? Or else?
Most media players employ the same strategy.
As scanning all the audio files and reading the tags is very time consuming, they do so once and store all the tags in a database.
Next time they scan the file system for changes.
Only if a file is modified, they read the tags anew.
This is much faster of course.
By now I think you could guess what happens when you change a tag e.g. art work and suppress changing the date modified :)
Got it.
The thing is that I don't use any kind of media library, I just use the file system.
Even on portable MP3/Flac player I do not browse things like "Artists" or "Albums" but rather "Folders",
Most media players employ the same strategy.
As scanning all the audio files and reading the tags is very time consuming, they do so once and store all the tags in a database.
Do they? Do they store all the album art in a database? It isn't a searchable text field, so ...
foobar2000 mobile has an in-memory image cache, including memory for pre-resized images for different display intents, but I don't know what desktop foobar2000 does in that regard.
Oh, and putting this out here: Remember, Windows Media Player on Windows 10 now (probably at least since 1803) defaults to only tagging in a central database, and has to be instructed to actually alter files on disk.
Do they? Do they store all the album art in a database? It isn't a searchable text field, so ...
Not necessarily in a database but the ones known to me like JRiver, MusicBee, WMP, etc do extract the coverart and store them in a cache.