Hi, I had previously raised a support request regarding this and it was solved and after clearing the tag cache the album arts for FLAC files showed up correctly. The issue occurred again when I tried to add ~46MB FLAC file to my google drive, this time I checked the file as previously mentioned by you and replaced the image with a much smaller size and then tried again but it didn’t work.
I faced this issue while updating a song with higher quality than the previous one. I tried deleting the old file permanently and then resyncing the app after uploading the new file but again no album art is displayed but the song does play in the app.
Did you remove the excess padding from the flac file?
That can be achieved by for example running this command using the flac cli on your file. flac --best --verify --force --padding=4096 *.flac
Note that this only works if you have the flac.exe in your PATH.
What the command does is reencode all .flac files in the folder in which it was executed with maximum compression, overwrite the existing files and set the padding to 4096kb. That removes excess padding left behind in the files from a large embedded image.
Alternatively, if you have mp3tag installed, you can use the new option described here instead to only adjust the padding size without reencoding.
Short version: Drag the song into mp3tag, right click it and use Utils → Optimize FLAC which will also set the padding to 4096kb.
As he said, if you do not compact the file then it’s still a 12Mb block.
I’ll increase again a little more the max block size, but at some point there’s limits about network usage and memory usage. 12MB cover that’s a little insane.
Thank you soo much This solved the issue. If you don’t mind me asking can you explain me what’s padding?. I really don’t know much about tags, links or docs to get started with tags will be helpful, you can dm me or reply here
Padding is extra space in the file with the purpose to allow tag changes without having to rewrite the file.
Case 1:
If you don’t have padding and you add new metadata or change it (which has to be stored in the metadata section of the file) the entire file is rewritten to increase the metadata section to store these new tags. That is really slow.
Case 2:
If you have padding (extra free space reserved for tags within the file) you can change or add tags and as long as you don’t add more data than the current padding, only the padding portion of your file will be changed, which is very fast.
Case 3:
If you have padding but you add something that exceeds the padding, the file also has to be rewritten with a bigger portion reserved for metadata. That usually happens when you embed large images in your tracks.
The thing most people don’t know is that even if you later on remove the embedded images, the padding is not automatically shrunk back.
Which is why you can end up with needlessly bloated files if you’re not aware of it.
For example an album with 20 tracks and an embedded 3MB cover uses 60MB of space only for the cover. If you extract the 3MB cover and store it in the folder instead of in the tag, you can save these 60MB (or rather 57MB as you still store the image once, in the folder) by performing one of the steps I described to you above (after removing the embedded image ofc).
Another downside of having large embedded files is a slower scan time as the entire tag portion of the file is usually read (that depends on the software tho).
You can notice that even when browsing into a folder with music and the explorer slows to a crawl and displays the thumbnails for your files line after line. If your files are optimized you can traverse your music library without any stuttering or loading.
If you still have a hard time understanding padding, you can look at one of your files in a hex editor (I use ImHex).
On the right side you can see your tags (Conceiving You by Riverside in my case) and the zeroes following the tag section is the padding. Basically you simply decide how many 00s you want to add after the currently stored tags to allow for future changes.
The difference between unoptimized and optimized audio files can be quite brutal.
500 unoptimized tracks might take 10 seconds to load into mp3tag while fully optimized it can load 6000 tracks in 4 seconds (actual experience on my end both loading from an m2 SSD to avoid hardware or network bottlenecks).
That depends on the scale at which you want to do it.
For 1 album at a time (good place to start and test for yourself if it’s something you want to do on a bigger scale):
Just open the album in mp3tag, in the tag panel on the left it should display the embedded cover(s) for the selected file(s).
Right click the cover → Extract cover…, save it in the folder of the album.
Then right click the cover in mp3tag again → Remove cover
Followed by CTRL + S to save that change.
After doing that you can perform one of the steps I described above to remove the excess padding.
If you however want to do it on many albums at the same time you can check the mp3tag forum, people there have devised actions which allow for batch extraction of album art to perform on many albums at once.
I’ve got to go for a few hours now but feel free to ask me more if you run into problems or have more questions.
It’s not just the software but the protocol. You can’t seek over http so either read or reopen another connections that may be worse in most cases specially GDrive.
I’m back. I found the official how-to that can batch export your covers, should you decide to do it on a big scale. Here’s the guide.
I’d consider testing that on a test structure of 5ish albums by different artists to ensure that it actually does what you want before using it on your actual collection. Also have a recent backup ready in case something unexpected happens.
Interesting, I didn’t know that. I stumbled upon the whole topic many years ago when I realized that dBpoweramp CD Ripper had embedded all the 2,5MBish covers into each of my songs that I had shot with my DSLR which led me to remove them on 150.000+ tracks at the time and then I reencoded all of these to reclaim the space. I think I did save around 200GB just by doing that.
btw.:
An added benefit of doing this instead of using the mp3tag utility to reduce the padding is that --verify means that the checksum that each flac file stores will be checked upon decoding and if it does not match the decoded audio data, an error is thrown.
That way you can kill a few flies with one stroke.
a) you remove excess padding and set a reasonable padding to ensure fast tag edits
b) you encode with the most recent and efficient encoder and save a bit of space
c) you check that all your flac files are not corrupt
If you’re not comfortable with using the command line you can also use dBpoweramp. That’s paid software with a very capable converter. foobar2000 can also recompress flac files, however I never found a way to make it use all my threads so I can’t speak to how well that works. It is free tho.
I used to use dBpoweramp, but it annoyed me that you can’t update the flac encoder manually without paying for an upgrade of the entire software suite so I coded my own multithreaded converter in a python script which traveres directories and reencodes all flac files it finds, pegging the 32 threads of my cpu. And after it has recompressed every .flac file, it calls rsgain on the same directory, which adds replaygain tags to all music files recursively (not only the flac files).
Hey there, I am facing an issue playing a FLAC file probably again due to some padding or other metadata issues ig. I have a 24/96 FLAC file it shows in symfonium but it plays as 16/44. Any ideas why?
That sounds like an unrelated issue. Which software displays to you that the song is 24/96 and in contrast, which only shows 16/44?
If you clearly want to identify the file you could check it out with mediainfo, which displays something like this for a “real” high res file.
Also if you want to check if a high res file is actually high res and not just upsampled, you can use sox to generate a spectrogram for the file like this:
sox "08 Shokufan.flac" -n spectrogram
Just replace “08 Shokufan.flac” with the name of the song.
You will end up with a spectrogram in the same folder in which you ran that command.
They look like this:
That’s also useful if you want to check if a flac file has been transcoded from mp3 as there will be a hard frequency cut-off at around 16khz and clearly missing information.
I have installed the mediainfo app and it display’s the file as “2941 kb/s, 96Khz, 24bits, 2channels, FLAC”. Symfonium displays 24/96 but when I click on play it plays as 16/44. I may not respond now but will later, because I’m gonna go sleep now its 12:25AM while writing this
Odd, mine displays the same values, both in the song list and during playback (24/96 both times).
Maybe your device can’t play 24/96 so it’s downsampled on the fly?
That’s something @Tolriq would know.
This solved the issue. If you don’t mind me asking can you explain me what’s padding?. I really don’t know much about tags, links or docs to get started with tags will be helpful, you can dm me or reply here 
