Adding album art to FLAC files is very slow

#1

I've been using Mp3tag for several years, and for as long as I can remember, writing 100 KB album art to FLAC files has been very slow if the files must be rewritten. It might take a minute or two to update a dozen files 20-40 MB each. This is happening again with Mp3tag 2.57 on my new build, which is an i5 4670 with 16 GB RAM. While the source and destination drives are the same WD green drive, this is still inexplicably slow and far slower than simply duplicating the files. It is actually far faster for me to load the FLAC files into EZ CD Audio Converter, add the album art, and transcode to ALAC. For example, I just now added the same 95 KB album art to these two sets of files lacking album art, all of which have been on my hard drive for several months so there is no prior caching to influence the results:

EZ CD Audio Converter, 12 FLAC files, 345 MB total, transcoding to ALAC + adding album art, 1 thread: 17 seconds

Mp3tag, 12 FLAC files, 264 MB total: 73 seconds

As it often does, Mp3tag got through the first six files pretty quickly, but then it bogged down on file seven and after, which took up most of the time. Any ideas?

ETA: The OS is Windows 7 x64.

#2

Hard disc caching

#3

Any idea why Mp3tag performs so poorly in comparison to Windows file copying and EZ CD? As I said, there was no prior caching going on, so Mp3tag must be doing something different than the other software. I haven't looked at its I/O pattern, but it's acting sort of like it's reading and writing very small blocks with no internal buffering to get its 7 MB/sec overall throughput.

#4

How much tag padding is being added when you initally rip or create these FLAC files. Many rippers will add a bit of tag padding so that if changes are made to the file tags later (including embedding album art), it won't have to rewrite the entire file to hold the tag changes. It may be that your FLAC files don't have enough padding. This is definitely more likely with artwork given its size.

In my own case, I put a single copy of the album art in the subdirectory containing the album (cover.jpg or folder.jpg) and this doesn't require embedding the art at all.

#5

Avoiding the need to rewrite the files isn't really the point. The point is that it's over 4x faster to simultaneously transcode to ALAC and add album art in EZ CD using a single thread than it is simply to add album art in Mp3tag. It's at least twice again faster to simply duplicate the files with Windows Explorer. I would expect rewriting files merely to add album art to go about as quickly as duplicating the files. It's mind-boggling that it takes 4x as long as transcoding to ALAC and adding album art.

Something is seriously suboptimal with the way Mp3tag is doing this.

#6

I don't know the technical details personally, but my educated guess would be that it would always take longer to "rewrite" the existing files to contain new tag data in addition to the audio data than to simply copy/duplicate the file itself. More is being done in the former case (and internally tested to not mess up the moving of the audio data). But again, I can't speak to the technical reasoning for this; someone else will have to chime in....

#7

I don't know the details either, which is why I said "about as quickly". Again, it's mind-boggling that simultaneously transcoding to ALAC and writing album art is over 4x faster. It should be expected that Mp3tag would fall somewhere in the middle, between this 4x operation and 8-9x file copying, and my feeling is that it should be much closer to the latter, unless the FLAC file format is so incredibly borked that adding metadata is akin to transcoding the file. (Which I don't believe.) For Mp3tag to be the 1x operation in all this, something has to be seriously suboptimal.