Currently Kid3 removes the padding of a flac file whenever a picture is removed. I do not know if this is picture specific or if this is somehow linked to some automagic for to large padding blocks after removal of the picture. I really like to keep the padding, since i work on a slow internet connection and the rewrite of the file causes a huge delay. Thus, I propose to: 1. add an option to never remove a padding block. 2. add an option to add a padding block whenever a flac/vorbis file is edited, which does not have such a padding block. Option 2 should have a parameter to specify the size of the padding block. This configured size should also be used if a padding block is used up by increasing metadata and the audio content needs to be shifted anyway. Operating System: Gentoo Linux KDE Plasma Version: 5.21.2 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.11.6-gentoo OS Type: 64-bit Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-3770 CPU @ 3.40GHz Memory: 30.9 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000
My answer is similar than in https://bugs.kde.org/show_bug.cgi?id=434551. Please check if this also happens with TagLib. Such behavior is not under the control of Kid3. Kid3 will try to remove the whole tag (thereby also removing the padding) when the tag is explicitly removed (using the "Remove" button), but not when only a frame is changed. I say "try" because it depends on the 3rd party library which does the actual tagging if it allows complete removal and if it does not remove the padding in other situations.
I have retested this one with taglib. taglib actually behaves in the way I described as my desired setting described above. I.e., it does not remove padding and it auto-adds a padding of 4k whenever a file is edited without a padding. Thus, my personal problem is solved here. However, I was wondering if there is a reason to actually enable the OggFlacMetadata plugin by default if taglib better handles this case.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
already provided info
Closing this because a workaround exists - use TagLib 1.12 if available.