Image 01


Urs Fleisch
MP3 Taggers

MP3 Taggers 217 comments

Score 86.5%
May 10 2020
I have added packages to my PPA for Ubuntu 15.04 which use Qt 5 and KDE 5, see - Mar 21 2015
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 script. - Dec 25 2014
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 ( 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.
- Nov 15 2014
Is now committed to Git. - Nov 13 2014
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. - Nov 12 2014
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. - Dec 17 2013
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. - Dec 12 2013
I will try to fix this soon. - Dec 11 2013
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. - Dec 11 2013
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. - Dec 05 2013
Thanks again for testing, I can confirm this, but it does not only affect version 3.0, but also earlier versions as it is a breaking change in the KDE libraries. More details can be found in the bug report (, there is a patch ( and the fix is also in Git.

A workaround to get the menus back is to delete ~/.kde/share/apps/kid3/kid3ui.rc. To use the fixed file, make sure that it is copied to the system configuration either by doing a real installation or by copying it manually. The fixed file can be found in the source tree at src/app/kde/kid3ui.rc and has to be copied to /usr/share/kde4/apps/kid3/kid3ui.rc (or where this file is located in openSUSE, see kde4-config --locate kid3/kid3ui.rc --path data). - Oct 29 2013
I could not reproduce these two issues, I suppose these are still aftereffects of the lost configuration.

1) I collapse Tag 1 as I have no need for it but it keeps getting expanded if a) I delete a field in Tag 2 when all files are selected b) I click a file name (left window) (..) previously Tag 1 always stayed collapsed

This sounds as if you had Settings/Auto Hide Tags unchecked before but now checked.

previously double clicking a mp3 started the integrated player

This sounds as if you had Settings/Configure Kid3.../User Actions/Play on double click checked before but now unchecked. - Oct 28 2013
Ignore - was resend of browser. - Oct 27 2013
Sorry, you are absolutely right, I noticed that the conversion of the old configuration does not work correctly for the KDE version. I have published a patch at or you could get the latest version from Git. Unfortunately, your old configuration is lost if you do not have a backup. I would suggest to delete it (~/.kde/share/config/kid3rc), so you can start with a default configuration which should be better than the "converted" configuration. Sorry for this nasty bug, maybe I will release 3.0.1 so that others are untroubled by this bug. - Oct 27 2013
Sorry, you are absolutely right, I noticed that the conversion of the old configuration does not work correctly for the KDE version. I have published a patch at or you could get the latest version from Git. Unfortunately, your old configuration is lost if you do not have a backup. I would suggest to delete it (~/.kde/share/config/kid3rc), so you can start with a default configuration which should be better than the "converted" configuration. Sorry for this nasty bug, maybe I will release 3.0.1 so that others are untroubled by this bug. - Oct 27 2013
Thanks for reporting, here is a patch: - Oct 25 2013
Sorry for the late answer, I was on holiday last month. Your shell script looks good, the shell will execute the lines in your script sequentially (asynchronous execution would need a '&' after the command). - Jun 02 2013
First a suggestion for your workflow: I think that it would be better to first convert to ID3v2.4 and then apply the UTF-8 encoding. ID3v2.3 does not support UTF-8, so if you apply UTF-8, it will set UTF-16. When you first apply UTF-8 to your ID3v2.3 files and then convert them to ID3v2.4, you will end up with ID3v2.4 files having UTF-16 encoding.

You are right, I don't like Kid3 to manipulate data without the intervention of the user. What about the following workaround: You create a script (e.g. Python or bash) which calls the following D-Bus commands: selectAll, convertToId3v24, applyTextEncoding. You can then add this script as a user action and start it from the context menu of the file list.
- Apr 25 2013
I think openSUSE has a problem with TagLib. From what I see, you have problems with programs which use TagLib (Kid3, amaroK, probably also VLC). In your screencast, I can see that the encoding byte is always 0 (ISO-8859-1) not 1 for UTF-16 (IDv2.3.0) or 3 for UTF-8 (ID3v2.4.0). I can also see that you are able to create an ID3v2.3.0 tag with something like UTF-8, however, UTF-8 is not supported with ID3v2.3.0 (and I am not able to create something like this with Kid3). There exists a bug report for openSUSE for some time, maybe you have such a "patched" TagLib. Try to install a TagLib from openSUSE 12.1 or one of the fixed versions mentioned in the bug report: - Apr 10 2013
First we should check what is wrong with the file. Please take an existing MP3 file or just create an empty file using "touch umlaut.mp3", then in Kid3 set title to "äÄöÖüÜß" and artist to "Artist". On my system (Ubuntu 12.10) the tag looks like this:

urs:~$ xxd umlaut.mp3 | head
0000000: 4944 3304 0000 0000 081b 5449 5432 0000 ID3.......TIT2..
0000010: 000f 0000 03c3 a4c3 84c3 b6c3 96c3 bcc3 ................
0000020: 9cc3 9f54 5045 3100 0000 0700 0000 4172 ...TPE1.......Ar
0000030: 7469 7374 0000 0000 0000 0000 0000 0000 tist............
0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................

From what I see, the tag seems to be OK. I could also see the umlauts when opening the file with iTunes on Mac OS X. On Linux, I could see the tag with VLC (uses TagLib) and mp3diags. Which program tells you that the tag is corrupt? Is your tag identical to mine?

I personally use ID3v1.1 and ID3v2.3.0. There are devices which do not support ID3v2.4.0, so IMHO ID3v2.3.0 is the better option. - Apr 10 2013
These libav libraries normally stem from a common source, either from ffmpeg or the libav fork. I guess that you are using ffpmeg-1.0.5, at least that's what seems to be available for openSUSE at the moment, and I can reproduce it with this version if I build it with --enable-avresample. Try the following patch: - Mar 11 2013
Which version of libav are you using? I tested it with libav 0.8.3, 0.8.5, 9.1. The change to libav-9.1 not only deprecated half of the API which is "normal" for libav, but also made the internals incompatible: First I had to fix a crash, then decoding was no longer working because the decoded data is now planar instead of packed and libavconvert cannot convert the planar data, so I switched to libavresample. Until a solution for your libav version is found, I recommend that you switch to GStreamer passing -DWITH_GSTREAMER=ON to cmake. - Mar 11 2013
You can now do that with version 2.3: Go to Settings/Tags/Tag 2/Quick Access Tags and select Album Artist and Compilation. - Mar 11 2013
This option is now included in version 2.3. - Mar 11 2013
I have added such an option and committed it to Git. - Jan 24 2013
Just some ideas why you could have had problems with your format:
  • Maybe you have activated "Format while editing" in the "Files" tab of the settings and a "String replacement" for "." to "".

  • You have to press the corresponding "From" button to actually format the filename. Then you can see the generated filename in the "Name" line edit, so you can see if the changes are OK before saving.

  • Quote:
    Why not just give us a single input to set the format we want?

    Before version 1.4, there was a single format, but on 2010-02-07 I received a user request by e-mail for separate formats. I implemented it because there is a reason for separate formats: The two operations are not completely inverse. Whereas the "To" operation uses the full path information (e.g. in "%{artist} - %{album}/%{track} %{title}" to get the artist and album from the directory name), the "From" operation only uses the filename (e.g. "%{track} %{title}"). To rename or create directories based on the tags, you have to use "Tools/Rename Directory". Before this separation, some users were confused because the directory part in the formats had no effect in the "From" operation.

    - Oct 31 2012
    I can not reproduce this. You can type whatever you like into the format combo box. It will try to complete the text entered with the values which are already in the list of the combo box, maybe this is replacing your format. But this should not prevent you from entering your format - just go on and edit it. If you want to edit the predefined entries of the format combo boxes, you can edit the line starting with "FormatItems" in ~/.kde/share/config/kid3rc or delete the line to get the default entries. - Oct 26 2012
    On are current packages for the latest Ubuntu release and the last LTS release, however only 32-bit packages because I have only a 32-bit installtion. If you want a 64-bit version of Kid3 2.1, you can try the package for the next Ubuntu release Normally, this should also work with Ubuntu 12.04. - Jul 16 2012
    with the current size it is difficult to target to a specific position in the song time.

    Could the seek slider icon be removed?

    I have removed the seek slider icon and put the seek slider together with the title label into a splitter so that the seek slider can be made larger.

    I also saw that the playbar has no name as other toolbars.

    Yes, I noticed this after the 1.5 release and fixed it in SVN. - Jan 23 2011
    ISO-8859-1 is the only encoding supported by ID3v1.1, so for these tags there is no choice.

    ID3v2.3 supports ISO-8859-1 and UTF-16, but not UTF-8 (if you select UTF-8 together with ID3v2.3 in Kid3, UTF-16 is used). UTF-16 uses two bytes per character whereas ISO-8859-1 uses only one character, so if most of your tags are in English, ISO-8859-1 seems to be a good choice using less bytes.

    ID3v2.4 supports UTF-8, and UTF-8 uses only one byte for ASCII characters, so this seems to be the best encoding for ID3v2.4. However, not all players support ID3v2.4, so if you want your MP3s to be compatible with all devices, you better use ID3v2.3 and ID3v1.1.

    Kid3 automatically changes the encoding to UTF-16 (for ID3v2.3) or UTF-8 (for ID3v2.4) if a string contains non-ASCII characters, so when choosing ISO-8859-1 and ID3v2.3 you have good compatibility and small size. If you do not like this default settings, it is easy to change them. - Jan 06 2011
    The enhanced "Number Tracks" dialog is ready to be tested. Get the latest code from Subversion. You can now enter the total number of tracks, and track numbers will be changed even if only the format is different. - Dec 13 2010
    I often want to clean the comment tag. So I want the field to be empty. But it's not possible to erase the content of the comment field.

    That's a "feature" of TagLib, the library which is used for ID3v2.4.0 tags. It was always in TagLib and I never liked it, but unfortunately, code using TagLib cannot circumvent this "feature". The "feature" is that TagLib will copy all standard tags which are missing in the ID3v2 tag from the ID3v1 tag and vice versa. In your case, you probably have the value "test" also in the ID3v1 comment field. If you delete the comment field in the ID3v2 tag, and then save the tags, TagLib will copy the "missing" comment field from the ID3v1 tag.

    TagLib 1.6.3, mpegfile.cpp, MPEG::File::save(), line 159:
    // Create the tags if we've been asked to. Copy the values from the tag that
    // does exist into the new tag.

    if((tags & ID3v2) && ID3v1Tag())
    Tag::duplicate(ID3v1Tag(), ID3v2Tag(true), false);

    if((tags & ID3v1) && d->tag[ID3v2Index])
    Tag::duplicate(ID3v2Tag(), ID3v1Tag(true), false);

    TagLib 1.6.3, tag.cpp, Tag::duplicate(const Tag *source, Tag *target, bool overwrite), line 74:

    This is done for all standard tags (title, artist, album, comment, genre, year, track). Possible workarounds are:

  • Use ID3v2.3 instead of ID3v2.4

  • Do not have both ID3v1.1 and ID3v2.4 tags in your files

  • If you have an empty standard tag in one of the tags, make sure that it is also empty in the other tag

  • Quote:
    Is it possible for you (I'm sure :-)), to add an option, that the loaded tracks will automatically be converted to a specified tag format (ID3v2.3 or v2.4)? So that Kid3 e.g. converts all tracks automatically to ID3v2.4 (like the convert function in tools, only that Kid3 would do it by default).

    I could, but I do not like such automatisms. I think that the user of Kid3 should have control over all tags and should not be controlled by software. The automatic tag duplication of TagLib is an example of such an automatism, which may be well-intentioned and useful for some users, but a nuisance for others. I provide the D-Bus interface and user commands for such stuff, so you could make a script which saves and then converts the tags if necessary. - Oct 09 2010
    After I finished tagging, I change the filename-format of the loaded tracks to (example): "01 - AcDc - Thunderstruck.mp3", based on the content of the id3-tags.

    This alone is no reason to pad the numbers with zeros. The %{track} format uses two digits by default, so a "%{track} - %{artist} - %{title}" format will produce your filename-format. You can also have more digits when using e.g. %{track.3}, %{track.4}, ...

    I tried to compile the source from Subversion under KDE 4.5.1, but I have some issues with kde-config (it's not there in 4.5.x)...

    You could get the openSUSE source RPM (see and use its kid3.spec and replace the source archive or apply the patch. Or you can find the packages required to build Kid3 in kid3.spec.

    In your last post, you wrote, that you think about implementing a function to apply the number format. That's great. But also think on the total number of tracks value in this case.

    The "track number digits" are already respected by the "total number of tracks", but the ID3v2.4-UTF8-bug also affects the total number of tracks formatting, so as long as you use ID3v2.4/UTF8 with an unpatched Kid3 1.5, it won't work.

    I will probably enhance the "Number Tracks" dialog to allow applying the number format and setting a value for the total number of tracks. Until then, the only thing I can provide is a little Python script to do it with a user command (again replace _ by spaces):

    #!/usr/bin/env python
    import dbus

    kid3 = dbus.SessionBus().get_object('net.sourceforge.kid3', '/Kid3')

    from PyQt4.QtGui import QApplication, QInputDialog
    app = QApplication([])
    total, ok = QInputDialog.getInt(None, 'Number Tracks', 'Total number of tracks:')
    print total, ok
    if ok:
    ____nr = 1
    ____while True:
    ________kid3.setFrame(2, 'track', '%d/%d' % (nr, total))
    ________if kid3.nextFile():
    ________elif kid3.previousFile():
    ________kid3.setFrame(2, 'track', '%d/%d' % (nr, total))
    ________if not kid3.nextFile():
    ________nr += 1 - Oct 03 2010
    I finally could reproduce the bug. It only occurs if you have ID3v2.4.0 together with UTF8 or UTF16. As I use ID3v2.3.0 with ISO-8859-1, I did not find the bug. The easiest workaround is to use ISO-8859-1. This is not as bad as it sounds because Kid3 automatically uses UTF8 (for ID3v2.4) or UTF16 (for ID3v2.3) if ASCII is not sufficient. Or you can use ID3v2.3.0.

    You can also build a fixed binary, e.g. by getting the source from Subversion or by applying the patch at

    I will think about implementing a function to apply the number format. Until then, you could use something like this little script and install it via Configure Kid3/User Actions:

    #!/usr/bin/env python
    import dbus
    kid3 = dbus.SessionBus().get_object('net.sourceforge.kid3', '/Kid3')
    while True:
    ____nr = kid3.getFrame(2, 'track')
    ____kid3.setFrame(2, 'track', '')
    ____kid3.setFrame(2, 'track', nr)
    ____if not kid3.nextFile():

    (replace _ by spaces) - Sep 28 2010
    Btw, what does "0" mean there? And "1" for tracks 10+, for that matter :)

    if (numDigits < 1 || numDigits > 5) numDigits = 1;

    "1" is normal behavior (no padded or truncated digits) as in printf() format.

    No effect that way either.

    Please try the following steps:
  • Settings/Configure Kid3, Track number digits: 2, OK

  • Edit/Select All

  • Click into Tag 2, Track Number field, then on Delete button, now all files have a disk icon because they are modified

  • Tools/Number Tracks, Start number: 1, Destination: Tag 2, OK, now all track numbers have two digits
  • - Sep 27 2010
    It does work, but not the way you expected it: Kid3 does not change any tags just because the configuration is changed. The configuration determines how tags are set, but they are only set if they are changed. This is also true for other configuration options, e.g. the tag format, the encoding or the ID3v2 version: they affect only changed tags. So in order to make the "digits in track number" effective, you have to change the track numbers, e.g. by selecting all files, deleting the track numbers using the "Delete" button and then using "Tools/Number Tracks". This is a bit complicated, but I do not want software to change data without user action. - Sep 27 2010
    Just released version 1.5 with (hopefully) all problems solved ;-) - Sep 25 2010
    There is now an "Auto Hide Tags" option in Kid3 1.5. - Sep 25 2010
    You have several (mysterious?) ways to do that:

  • Drag-and-drop an image file from a file manager

  • Drag and drop an image from a web browser (this can be guided using the menu File/Browse Cover Art...)

  • You can add a Picture frame (Button Add, then Picture, Import)

  • - Aug 03 2010
    There is usually a new release every 6 months. The next release will be in October. This gives me enough time for testing. If you want to use the latest features faster, you can get the code from Subversion. The code in the Subversion repository is supposed to be working, but it is not so thoroughly tested as official releases. - Jul 21 2010
    There was really room for improvement. I have optimized the filtering code and also the selecting of files. Please get the code from Subversion, it should be usable now. - Jul 20 2010
    Are you sure that the link is broken? It seems to point correctly to - Feb 22 2010
  • Open the root directory (File/Open Directory)

  • Tools/Filter, All, Apply, Close. Then all directories have been read in.

  • Edit/Select All

  • Tag 2, Button "Add", and add your custom tags.

  • File/Save and all your files will have the custom tags.

  • - Dec 23 2009
    Correction: The bug seemed to be fixed, but it was not really, because the patch was not applied. A new fixed package for OpenSUSE 11.2 is available: - Nov 25 2009
    Code for covers in Ogg is now in Subversion, both the old COVERART and the new standard METADATA_BLOCK_PICTURE fields are supported. - Nov 24 2009
    I have fixed this and checked the code into Subversion, so you'll have to get the latest code from SVN. The change is described in the commit message:
    Fixed bug: Select multiple files, edit tags 2 and mark fields, then tags 2 -> tags 1 => tags 1 are not changed and tags 2 are reverted.
    This bug was introduced in revision 568 by only updating the selection when a single file is selected after operations "Number Tracks", "Copy", "Paste", "From Filename", "From Tags 1/2", to avoid marking unchanged fields as changed due to transient setting of fields with a different value to an empty string.
    Both problems are solved by marking fields which are different in multiple files with a special value (Frame::differentRepresentation(), actually an unequal sign) and never setting such values to the tags (Frame operations "setValueIfChanged()" instead of "setValue(); setValueChanged()"), which makes it possible to always (and not only when a single file is selected) update the selection (updateCurrentSelection()). This affects the operations mentioned above plus "Apply Tag Format", "Apply Filename Format", "Convert ID3v2.3 to ID3v2.4", "Convert ID3v2.4 to ID3v2.3".
    Additionally the handling of multiple files is done separately for Tag 1 and Tag 2 to fix the following problem: Select frame without Tag 1 (e.g. m4a), then add one with Tag 1 (mp3), then select ID3 field, deselect files => ID3v1 fields are cleared.
    - Nov 22 2009
    In December 2008, I implemented support for COVERART/COVERARTMIME vorbis comments. However, they corrupted the Ogg files, so I never commited the code. Maybe this was a bug in libvorbis, but I could not find a bug report or change log about a fix. Probably I'll try again as I still have the code. But COVERART comments as implemented in EasyTag are now deprecated, the official recommendation is to use METADATA_BLOCK_PICTURE as in FLAC, see I will have a look at this, although libvorbis does not seem to support it at the moment. - Nov 15 2009
    This should fix your problem:

    Don't forget to start from clean sources to rebuild afterwards, because the configure check failed because of this bug and returned the wrong result for libmp4v2.

    You could also consider an update to a newer version of libmp4v2 - Nov 12 2009
    would it be possible to allow selection of browser instead of using xdg-open?

    This is possible with Settings/User Commands/Web Browser.
    it opens it's own window with possible covers

    I made the design decision to use the web browser to choose cover pictures because of legal/license issues: There are restrictions for automatically grabbing album cover art from Amazon, Google Images and probably also from other sources. Just opening a browser window should be legal. The second reason is that parsing HTML is not a long-term solution: As soon as the HTML changes a bit, the application will no longer work. For example, I had to fix the Discogs import code multiple times because of changes in the Discogs appearance which made HTML parsing no longer work. - Nov 10 2009
    I can reproduce it and I'll have a look at it. As a workaround, you can change the selection (e.g. deselect a file and then select it again) between the steps (here: change the tag fields and Tag 1 -> Tag 2), because this causes the tag fields to be set from the GUI controls. - Nov 10 2009