(this is written by claude because i wouldnt know how to write it in a professional manner)
Opus files with a large embedded cover make Mp3tag very slow. "Reading directory" takes a long time and the
window stops responding (Windows logs it as AppHangTransient). Selecting the file in the list freezes it again for
about the same time. A FLAC with exactly the same cover image opens instantly.
Version: Mp3tag v3.37 (64-bit), Windows 11
File: Opus (Ogg), 2:32 min, 24 MB. The cover is a 3000x3000 JPEG stored the standard way as a base64
METADATA_BLOCK_PICTURE Vorbis comment (written by mutagen; same result with files from other taggers).
Measured with the same file, only the embedded cover changed (time Mp3tag stays busy after opening a folder
that contains only this one file):
Cover 3000x3000 JPEG, 15.2 MB -> ~13 s (CPU-bound, ~13 s CPU time)
Cover 3000x3000 JPEG, 4.0 MB -> ~1.6 s
Cover 3000x3000 JPEG, 2.5 MB -> ~1.3 s
The time grows much faster than the cover size (about 4x the cover size -> about 8x the time). That looks like
non-linear work, perhaps in reassembling the comment packet across Ogg pages or in base64 decoding. The same
15 MB image in a FLAC PICTURE block shows no delay at all.
Steps to reproduce:
- Take any Opus file and embed a ~15 MB JPEG as front cover.
- Open its folder in Mp3tag -> long "Reading directory", window not responding.
- Click the file -> freezes again.
Thanks for the great tool btw!