# Opus files loading very slowly **URL:** \ **Category:** Bug Reports\ **Created:** [November 14, 2026, 12:24am UTC](https://community.mp3tag.de/t/opus-files-loading-very-slowly/72075 "2026-11-14T00:24:13Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Gumball](https://community.mp3tag.de/user_avatar/community.mp3tag.de/gumball/32/23987_2.png) [@Gumball](https://community.mp3tag.de/u/Gumball)\ **Post date:** [November 14, 2026, 12:24am UTC](https://community.mp3tag.de/t/opus-files-loading-very-slowly/72075/1 "2026-11-14T00:24:13Z")
(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: 1. Take any Opus file and embed a ~15 MB JPEG as front cover. 2. Open its folder in Mp3tag -\> long "Reading directory", window not responding. 3. Click the file -\> freezes again. Thanks for the great tool btw!