Version: 1.2.3 (using KDE KDE 3.3.2) Installed from: Debian testing/unstable Packages OS: Linux When editing meta-data of MP3 files, only ID3v1 tags are written back to the file, no matter whether the file had ID3v1, ID3v2 or both tags before. This means data is lost whenever meta data is edited that exceeds ID3v1's 30 char limitation.
I think amaroK should give an option to write ID3v1, ID3v2 or both (maybe the dialog should be like XMMS's ?). That's one more reason I prefer OGG over MP3 anyway.
I can't confirm this one using debian/sid's amarok 1.2.4 version. Amarok does write correct ID3V2.4 tags. What did you do to check if the tag was correct? Maybe your app didn't know of revision 4 of ID3V2 and ignored the tag?
Thye thing is that if you don't enable recoding of ID3v1 tags, ID3v2 tags work great. When you enable recoding ov ID3v1, ID3v2 are simply ignored.
*** Bug 110751 has been marked as a duplicate of this bug. ***
There should be a clearly marked option to disable ID3v1 fields alltogether. Furthermore, for tags with previous embedded album cover image, this image is consistently deleted by amaroK when making other changes to the tag. While amaroK does not support storing new album covers in the ID3 tag, it should NOT remove album covers already present. This must be marked as a bug.
Changing summary to better reflect the problem.
*** Bug 100742 has been marked as a duplicate of this bug. ***
*** Bug 113106 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
This report is no longer valid. In amaroK SVN we have removed all recoding options entirely. So amaroK will always write ID3V2 tags.
bug 101166, bug 108469 and bug 116270 should be closed too, then?
also, bug 98745