Available as/for:release-stablesource-packagex86-64
Description: If you want to easily tag multiple MP3, Ogg/Vorbis, Opus, DSF, FLAC, MPC, MP4/AAC, MP2, Opus, Speex, TrueAudio, WavPack and WMA files (e.g. full albums) without typing the same information again and again and have control over both ID3v1 and ID3v2 tags, then Kid3 is the program you are looking for.
With Kid3 you can: - Edit ID3v1.1 tags - Edit all ID3v2.3 and ID3v2.4 frames - Convert between ID3v1.1, ID3v2.3 and ID3v2.4 tags - Edit tags in MP3, Ogg/Vorbis, FLAC, MPC, MP4/AAC, MP2, Speex, TrueAudio, WavPack, WMA, AIFF and WAV files - Edit tags of multiple files, e.g. the artist, album, year and genre of all files of an album typically have the same values and can be set together. - Generate tags from filenames - Generate tags from the contents of tag fields - Generate filenames from tags - Rename and create directories from tags - Generate playlist files - Automatically convert upper and lower case and replace strings - Import from freedb2.org, MusicBrainz, Discogs, Amazon and other sources of album data - Export tags as CSV, HTML, playlists, Kover XML and in other formats - Edit synchronized lyrics and event timing codes, import and export LRC filesLast changelog:
Kid3 3.9.6
Sat Sep 21 08:03:29 CEST 2024 Urs Fleisch * Release 3.9.6 * New: + Show preview for multiple embedded pictures. + Simplified editing of MP3 audiobooks in a "Chapters" frame edit dialog. + Arabic, Esperanto, Galician and Georgian translations. * Improved: + macOS: Building, signing and notarizing packages. * Fixed: + Embed lyrics action. + gnudb.org import, a registered e-mail address can be set in the "Token" UI control. + KDE 6: Install directory for kid3ui.rc. + Android: Building with arm64-v8a and x86_64 architectures. + Android: Use MANAGE_EXTERNAL_STORAGE permission to manage all files on a storage device. + Android: Saving picture tags. + Haiku: Installation paths.
Thx for kid3 and inode/directory in desktop file, that will be part of next release.
So before I forget it, let's document it here:
You mentioned an old problem of a user with kid3 used as default app for directories (instead of dolphin). In case this pops up again one can check https://bugs.kde.org/show_bug.cgi?id=220806 for a IMHO hackish fix with a second desktop file. (But hopefully with D.Faure help this will soon list the proper fix ;-) ).
Achim
I've found a little bug in an otherwise really great tool: The suggested default filename in kid3 when exporting a cover is always folder.jpg, even when the cover in the mp3 is image/png.
As 'export' does no convertion png->jpg one has to 'fix' extention of the suggested filename to
be folder.png.
Would be nice if the default filename: folder.(jpg|png) would be determined by the mimetype.
Thx a lot for a great tool!
Achim
Thanks for the suggestion, I will consider it, however, probably only for Qt5 because QMimeType does not exist for Qt4. The problem with Qt5 is that no file name at all is set in the standard GTK dialog, only with the Qt file dialog. I could not check if it works with the KDE dialog because I do not have KDE 5 installed at the moment and KDE 4 file dialogs do not seem to be supported in Qt5. With Qt 5.4 beta, it seems to be fixed, so I could test it.
Thx, a lot! Looks like I've to setup a Framework 5 build environment ...
Have you an estimate when a kid3 for Framework5 will be released?
About qt/4KDE4: At least the for KDE4 variant of kid3:
The dialog that pops up when one double click the cover contains already the mimetype (my guess: taglib returns this info?). So maybe one can use these info to feed the right name into the dialog opened by 'export...' button for KDE4?
On the other hand a kde/qt4 fix is maybe not worth the extra work with plasma5/framework almost ready for endusers.
Thx a lot again.
Achim
Have you an estimate when a kid3 for Framework5 will be released?
Kid3 actually does not have a lot of KDE specific code, just the main window, the configuration dialog and some other dialogs. Most of the code is shared between the KDE and Qt-only versions. Qt5 is supported for quite some time, so I do not expect that it will be a lot of work. However, I will probably wait until some of the core applications have been ported, so that I can be confident that the API and the build system are more or less stable. And I would like to have a KDE 5 installation running on my PC, preferably from the official repositories, so I can test the KDE 5 port.
I am not sure if KDE 5 will run decently on my PC. I suppose that it relies heavily on QML, and I am dealing with QML for some time now because I am making functions of Kid3 accessible via QML. The sad thing is that QtQuick2 (i.e. the QtQuick from Qt5) is running incredibly slow on my PC (HP Compaq DC7800), probably because the QtQuick2 scene graph uses OpenGL functions which are not well supported by the Intel GMA 3100 graphics driver. I have to set LIBGL_ALWAYS_SOFTWARE=1 to use software rendering instead of the sluggish GPU. On my laptop (HP Compaq N610C), which has an ATI Mobility Radeon 7500, QtQuick2 does not work at all, it just crashes. On Qt4, QtQuick works well (using the raster engine), and debugging is much better because the QML/JS Console works, which is not the case in Qt5 (QTBUG-37119). What makes things worse is that using the same QML codebase for Qt4 and Qt5 has been made impossible because Qt5 refuses to import QtQuick 1.0 although most code would run without problem. This not comprehensible design decision to force users to use QtQuick2 "and never look back" together with the lack of something like a preprocessor forces me to use a script (https://katastrophos.net/andre/blog/2013/09/20/qml-preprocessor-the-qnd-and-kiss-way/) to modify the code whenever I switch between QtQuick1 and QtQuick2.
So my question is whether KDE 5 will be usable with PCs which do not have the latest generation of GPUs. Qt and KDE may focus on mobile and touch based devices (which have good GPUs) but most users will still run KDE on a PC, and not all users buy a new PC every year. As you can see, my enthusiasm about Qt5 is not unlimited. Another source of frustration is the poor support for the Windows/MinGW version. As long as the footprint is so huge (QTBUG-29828) and every application can be crashed using command line arguments (QTBUG-30330) I will use Qt4 for the Windows version.
Have you an estimate when a kid3 for Framework5 will be released?
I have ported Kid3 to KDE 5 and committed it to Git. Just pass "-DWITH_QT5=ON" when calling cmake. It you want to create a Debian package for KDE 5, modify the files in the deb/ folder according to the comments (just grep for "KDE 5"), then start the build-deb.sh script.
Hi. dont know if this is a kid3 bug or some building bug of debian.
in 3.0.2 i can change things in opus, with the Qt(4) only version.
if i try to open an opus file in the KDE Edition, it wont work.
both where build with libopus 1.1 as well as taglib 1.9.1
beside this.. its a great app and my favorite tagger (: THANK YOU!
I do not have a Debian sid installation, so I cannot exactly reproduce the problem. I built the original debian source package on Ubuntu 13.10, the KDE and Qt versions seem to behave the same, however, Ubuntu 13.10 uses TagLib 1.8, so there is no Opus support. I built Kid3 using a static TagLib 1.9, and Opus works both for kid3-qt and kid3.
Could you check if TaglibMetadata is available and enabled in Setting/Configure Kid3.../Plugins/Metadata Plugins & Priority of both the Qt and the KDE version? If this plugin is not available, you will not be able to open files of the formats ape, mpc, wma, opus, and others.
TaglibMetadata is available and enabled..
ok forget that is 'dont work'. I was just trying to take a screencast of the problem. first drag and drop didnt work, after that i've tried with "open with" and it has worked, now the drag and drop works too. really strange ..
http://youtu.be/D_oTBGdGjFg
I can explain this: If you open a file using the file dialog, the file list filter is set from the file type filter selected in the open dialog. Only files which match this wildcard pattern are displayed in the file list. If a file with an extension which is not in this filter is dropped into Kid3, it could not be opened. In your case the file filter contained the old "all supported files" filter (without Opus), so Opus files could not be dropped. When you opened the file dialog, the "all supported files" was updated to contain "*.opus". Then Opus files could also be opened via drag'n'drop. The different behaviour for kid3 and kid3-qt is caused by the different behaviour of the file dialogs. The selected filter in KDE seems to be "write-only" whereas it takes precedence in the Qt file dialog.
The behaviour is strange enough to justify a fix, so I have fixed it in Git. Now the file filter is removed in such situations.
Hi Urs.
I'm controlling Kid3 via. DBus calls from some scripts. Example: For selecting all files I use this command: "qdbus net.sourceforge.kid3 /Kid3 selectAll". That works nice. My problem is, in a former Kid3 2.x version (i'm now using 3.0.2) there was a Dbus function "expandAll" to expand the directory tree in Kid3. I used this in a shell script: "qdbus net.sourceforge.kid3 /kid3/MainWindow_1 expandFileList". The Dbus Method "epandFileList" isn't there anymore. With qdbusviewer I found a method called "expandDirectory", but it doesn't work.
Can you tell me, how and what DBus-Function I have to call to expand the directory tree?
Thx in advance.
Kai
Unfortunately, you are right, this must be happened while refactoring to separate the GUI from the application logic.
There seems to be a simple workaround:
qdbus net.sourceforge.kid3 /Kid3 filter ""
qdbus net.sourceforge.kid3 /Kid3 firstFile
while test "$(qdbus net.sourceforge.kid3 /Kid3 nextFile)" = "true"; do :; done
The filter command is used to load all files. Then all files are traversed which expands the tree in the GUI.
It is now fixed in Git. expandDirectory() should work as described in the handbook. There is also a new D-Bus command expandFileList() which expands the whole file list.
Ratings & Comments
219 Comments
10 thanks for the linux version
10 the best
10 10 the best
9 + my go-to music tagger!
9 +Very nice and simple tagger.
9 +Cool
Thx for kid3 and inode/directory in desktop file, that will be part of next release. So before I forget it, let's document it here: You mentioned an old problem of a user with kid3 used as default app for directories (instead of dolphin). In case this pops up again one can check https://bugs.kde.org/show_bug.cgi?id=220806 for a IMHO hackish fix with a second desktop file. (But hopefully with D.Faure help this will soon list the proper fix ;-) ). Achim
I've found a little bug in an otherwise really great tool: The suggested default filename in kid3 when exporting a cover is always folder.jpg, even when the cover in the mp3 is image/png. As 'export' does no convertion png->jpg one has to 'fix' extention of the suggested filename to be folder.png. Would be nice if the default filename: folder.(jpg|png) would be determined by the mimetype. Thx a lot for a great tool! Achim
Thanks for the suggestion, I will consider it, however, probably only for Qt5 because QMimeType does not exist for Qt4. The problem with Qt5 is that no file name at all is set in the standard GTK dialog, only with the Qt file dialog. I could not check if it works with the KDE dialog because I do not have KDE 5 installed at the moment and KDE 4 file dialogs do not seem to be supported in Qt5. With Qt 5.4 beta, it seems to be fixed, so I could test it.
Is now committed to Git.
Thx, a lot! Looks like I've to setup a Framework 5 build environment ... Have you an estimate when a kid3 for Framework5 will be released? About qt/4KDE4: At least the for KDE4 variant of kid3: The dialog that pops up when one double click the cover contains already the mimetype (my guess: taglib returns this info?). So maybe one can use these info to feed the right name into the dialog opened by 'export...' button for KDE4? On the other hand a kde/qt4 fix is maybe not worth the extra work with plasma5/framework almost ready for endusers. Thx a lot again. Achim
Quote:Have you an estimate when a kid3 for Framework5 will be released?
Kid3 actually does not have a lot of KDE specific code, just the main window, the configuration dialog and some other dialogs. Most of the code is shared between the KDE and Qt-only versions. Qt5 is supported for quite some time, so I do not expect that it will be a lot of work. However, I will probably wait until some of the core applications have been ported, so that I can be confident that the API and the build system are more or less stable. And I would like to have a KDE 5 installation running on my PC, preferably from the official repositories, so I can test the KDE 5 port.
I am not sure if KDE 5 will run decently on my PC. I suppose that it relies heavily on QML, and I am dealing with QML for some time now because I am making functions of Kid3 accessible via QML. The sad thing is that QtQuick2 (i.e. the QtQuick from Qt5) is running incredibly slow on my PC (HP Compaq DC7800), probably because the QtQuick2 scene graph uses OpenGL functions which are not well supported by the Intel GMA 3100 graphics driver. I have to set LIBGL_ALWAYS_SOFTWARE=1 to use software rendering instead of the sluggish GPU. On my laptop (HP Compaq N610C), which has an ATI Mobility Radeon 7500, QtQuick2 does not work at all, it just crashes. On Qt4, QtQuick works well (using the raster engine), and debugging is much better because the QML/JS Console works, which is not the case in Qt5 (QTBUG-37119). What makes things worse is that using the same QML codebase for Qt4 and Qt5 has been made impossible because Qt5 refuses to import QtQuick 1.0 although most code would run without problem. This not comprehensible design decision to force users to use QtQuick2 "and never look back" together with the lack of something like a preprocessor forces me to use a script (https://katastrophos.net/andre/blog/2013/09/20/qml-preprocessor-the-qnd-and-kiss-way/) to modify the code whenever I switch between QtQuick1 and QtQuick2.
So my question is whether KDE 5 will be usable with PCs which do not have the latest generation of GPUs. Qt and KDE may focus on mobile and touch based devices (which have good GPUs) but most users will still run KDE on a PC, and not all users buy a new PC every year. As you can see, my enthusiasm about Qt5 is not unlimited. Another source of frustration is the poor support for the Windows/MinGW version. As long as the footprint is so huge (QTBUG-29828) and every application can be crashed using command line arguments (QTBUG-30330) I will use Qt4 for the Windows version.
Quote:Have you an estimate when a kid3 for Framework5 will be released?
I have ported Kid3 to KDE 5 and committed it to Git. Just pass "-DWITH_QT5=ON" when calling cmake. It you want to create a Debian package for KDE 5, modify the files in the deb/ folder according to the comments (just grep for "KDE 5"), then start the build-deb.sh script.
I have added packages to my PPA for Ubuntu 15.04 which use Qt 5 and KDE 5, see https://launchpad.net/~ufleisch/+archive/ubuntu/kid3/+packages.
Its a great tool. It helps me a lot to tag my music, create playlists and generate canonical file names.
Hi. dont know if this is a kid3 bug or some building bug of debian. in 3.0.2 i can change things in opus, with the Qt(4) only version. if i try to open an opus file in the KDE Edition, it wont work. both where build with libopus 1.1 as well as taglib 1.9.1 beside this.. its a great app and my favorite tagger (: THANK YOU!
I do not have a Debian sid installation, so I cannot exactly reproduce the problem. I built the original debian source package on Ubuntu 13.10, the KDE and Qt versions seem to behave the same, however, Ubuntu 13.10 uses TagLib 1.8, so there is no Opus support. I built Kid3 using a static TagLib 1.9, and Opus works both for kid3-qt and kid3. Could you check if TaglibMetadata is available and enabled in Setting/Configure Kid3.../Plugins/Metadata Plugins & Priority of both the Qt and the KDE version? If this plugin is not available, you will not be able to open files of the formats ape, mpc, wma, opus, and others.
TaglibMetadata is available and enabled.. ok forget that is 'dont work'. I was just trying to take a screencast of the problem. first drag and drop didnt work, after that i've tried with "open with" and it has worked, now the drag and drop works too. really strange .. http://youtu.be/D_oTBGdGjFg
I can explain this: If you open a file using the file dialog, the file list filter is set from the file type filter selected in the open dialog. Only files which match this wildcard pattern are displayed in the file list. If a file with an extension which is not in this filter is dropped into Kid3, it could not be opened. In your case the file filter contained the old "all supported files" filter (without Opus), so Opus files could not be dropped. When you opened the file dialog, the "all supported files" was updated to contain "*.opus". Then Opus files could also be opened via drag'n'drop. The different behaviour for kid3 and kid3-qt is caused by the different behaviour of the file dialogs. The selected filter in KDE seems to be "write-only" whereas it takes precedence in the Qt file dialog. The behaviour is strange enough to justify a fix, so I have fixed it in Git. Now the file filter is removed in such situations.
i think i understand it now & thank you for the fix (:
Hi Urs. I'm controlling Kid3 via. DBus calls from some scripts. Example: For selecting all files I use this command: "qdbus net.sourceforge.kid3 /Kid3 selectAll". That works nice. My problem is, in a former Kid3 2.x version (i'm now using 3.0.2) there was a Dbus function "expandAll" to expand the directory tree in Kid3. I used this in a shell script: "qdbus net.sourceforge.kid3 /kid3/MainWindow_1 expandFileList". The Dbus Method "epandFileList" isn't there anymore. With qdbusviewer I found a method called "expandDirectory", but it doesn't work. Can you tell me, how and what DBus-Function I have to call to expand the directory tree? Thx in advance. Kai
Unfortunately, you are right, this must be happened while refactoring to separate the GUI from the application logic. There seems to be a simple workaround: qdbus net.sourceforge.kid3 /Kid3 filter "" qdbus net.sourceforge.kid3 /Kid3 firstFile while test "$(qdbus net.sourceforge.kid3 /Kid3 nextFile)" = "true"; do :; done The filter command is used to load all files. Then all files are traversed which expands the tree in the GUI.
Thank you, your workaround is fine and fits my needs. Will the expandFileList command come back in a future version?
I will try to fix this soon.
It is now fixed in Git. expandDirectory() should work as described in the handbook. There is also a new D-Bus command expandFileList() which expands the whole file list.