I've been removing the "Album Artist" field from all my tags because I don't like the way some devices use it and some don't. So in order to not have any inconsistencies, I just decided to remove it altogether.
I'm doing this in bulk and so far I have found two ways to accomplish this. First is by loading all the files into Mp3tag > [ALT+T] > select "ALBUMARTIST" field > [DELETE] > click "OK". The second way is to load all the files in Mp3tag > Quick Actions > Remove fields > ALBUMARTIST > OK. The first method is much slower than the second and appears to have to rewrite each file one by one, whereas the second method seems to be much more efficient and finishes in seconds!
Can anyone explain what the difference is between using the two methods and what the pros/cons are of using one method over the other? I'm just curious on what's going on in the background that makes one method take longer than the other, when both seem to provide the same results.
I would say that ALBUMARTIST is a bad example for a field to be removed.
I cannot substantiate any problems in respect to
as any decent player uses ALBUMARTIST to group tracks for an ALBUM together if there are several different names in ARTIST. Otherwise you get 1 album per artist - which is often undesirable.
Coming to your observation in respect to performance: in general, a file gets rewritten if the padding space is not big enough any more when adding data to tags or when the padding becomes much more than the default padding space.
The underlying engine is the same for going the way with actions or using the extended tags dialogue.
So it would be a good test to first use one method and record the elapsed time, then restore the data and then do it again with the other method and then compare the time.
And perhaps you even add the 3rd way: remove the field via the tag panel.
Are you sure that you have restored your files after using the first method and rebooted your system to eliminate any involved caching mechanisms and the mentioned use of padding?
And btw: Do you use Mp3 or FLAC or any other format for your test?
Feel free to submit your feedback to Chevrolet, Subaru, Cadillac, Lexus and Maserati since out of all those vehicles I own, one of which has an aftermarket Pioneer headunit, not a single one uses the "AlbumArtist" field when displaying tracks. They all use Artist, Title and Album. It's a nuisance for me since the Apple devices I use do utilize the Album Artist field. But if I add a track to my library that doesn't have the AlbumArtist field populated and I forget to fill it in, then I get duplicate artists showing on the Artists screen. So it's basically a nuisance for me to have it and just easier to eliminate it altogether. It's not like it's a hard field to repopulate in the future if I really wanted to seeing as how all my music is organized in "Artist\Album..." folders. I could easily tag that field using my folder structure.
There's no way that's true and if it is, then there are some coding issues that need to be addressed. I've tested this multiple times and the results are repeatable every single time. I could upload a screencapture showing the process if need be, but this is very easy to reproduce if you'd like to test for yourself.
Source Files: 88 AAC tracks totaling 1.03GB
Copy all source files to RAM Disk.
Drag & Drop all the source files into Mp3tag.
Select All > View > Extended Tags > Delete AlbumArtist > OK
I get a "Writing Tag Data" popup with a progress bar and takes ~4 seconds to complete.
I get a "Writing Tag Data" popup that flashes so quick, I actually had to screen record the process because it happened so fast and I wanted to verify that it was the same popup window as before.
I repeated the exact same process above four times in a row and got the exact same results every single time. Using the "Extended Tags" to delete fields is SIGNIFICANTLY slower than using "Remove Fields". Note that I used a RAM Disk to rule out any latency or disk caching. But just to be sure, I even tested the same process with the files copied to an SSD and also on a HDD. My conclusion is that this has nothing to do with caching or anything like that. Feel free to test for yourself and you'll see what I'm talking about.
I tested with both FLAC and AAC files. The results were the same regardless of file type used.
You are right: I also see a detectable speed difference. Any process with actions is faster.
The GUI based processes (Converter, Tag Panel, Extended Tags Dialogue) take the same amount of time.
You are free to do with your files whatever you want. I just wanted to add my three pence to mention what I have learnt from various threads in this forum: if you have a decent player (and apparently the car stereos aren't) then it uses ALBUMARTIST.
My approach would still be to keep as much information as possible, as IMHO it is much more time consuming to restore deleted data. The pacemaker should be that device that can handle the most information, not the one that has the minimal implementation.
But again: that is completely down to individual preferences.
I know being a new member makes it hard to take anything serious, so I was ready to post up a screen capture if need be lol. But thank you for confirming and saving me the hassle of going thru all that extra work. Hopefully Florian will see this and can chime in with some insight.
I know and I agree with you 100% about keeping as much info as possible. I always try to keep as much data as possible without everything becoming too messy. But for me in this case, it's just easier to do without. And this is only for my AAC files that I've converted from FLAC which I still have the originals saved. I only converted to AAC because iTunes won't allow FLAC and I'm not going to convert all my FLAC files to ALAC just because of stupid Apple and iTunes. So instead, I just run a batch script to convert everything to AAC use the qaac library. What I need to do is get myself a respectable Portable Music Player and ditch my iPod altogether. But for now, this is what I'm workin' with.
The method via extended tags (or via the Tag Panel) has some extra code in place that makes updating the File List during the process much more smoother, especially when scrolling the list while the process is still doing its work.
The method via actions doesn't use this extra code at the moment. I should probably should also add it there, but I prefer the speed of operation over the ability to smoothly scroll the File List, so unless nobody reports this as a bug ...
This already should give you an idea about the pros and cons. Both methods are using the same code paths to actually write the files, so there is no difference in the result of both operations.
Car players often only display a limited number of tags. They may not even use them in their background processes either. But that shouldn't affect whether or not any tag is consistently used. It either is or isn't. Sounds like they are using a simple Folder/Filename structure and not a true library browser from the tags.
At least this way you have preserved the data. Strange that some of those cars at least don't support FLAC at this point. But if this is going onto a SD card or USB drive of some sort in lossy, does the mp3 format work any better in those cars? The id3 tag data is different than the m4a type used in aac files and may have more support for you.
That is Apple's way. But if you are using an iPod that is really your only choice. At least on newer iDevices with iOS you can install player apps that do support FLAC and other formats Apple doesn't natively play nicely with. Or move to a separate player altogether that can play your FLAC files as lossless and then the conversion won't even be necessary.
Just did another test tonight, removing the Album Artist tag on 4,665 AAC files...
via Extended Tags: ~3 minutes
via Quick Actions: ~3 seconds
IMO, I would definitely say that doing it via Extended Tags is the "buggy" option. Whatever extra code is there to make the process "smoother" I would say is not needed. I mean really, what is the point of having it be "smoother" if it takes almost 3-minutes to complete via Extended Tags? Who on earth would want to wait 3-minutes to modify tags on 4,665 files when it can be done in 3-seconds? Seems like you could easily get rid of that code to minimize footprint and make it faster at the same time. Sounds like a win/win to me lol.
Nah, they're definitely using tags. I tested this out by tagging an audio file with the name of each tag, i.e. Artist=Artist, Title=Title, Album=Album, Album Artist=Album Artist etc. This way when I play the file in each vehicle, I could see exactly which tags it was using. All of them were using the Artist, Title and Album tags from the AAC file being played on an iPod via Bluetooth. I didn't do any testing via SD Card or anything like that as I find the way that type of interface is used to be very unintuitive.
No difference with MP3. They all still read Artist, Title and Album tags, just as they did for AAC.
Yeah, I thought about installing a different music app to use, but considering the increased storage space requirements I'd need and seeing as how the bitrate of the Bluetooth codec that an iPod supports is nowhere near my FLAC files, I didn't even bother.
When using an iPod type device on most car players connected by USB, the interface is pretty consistent. Like most things they do, this is controlled by Apple. While what you see on the car display may be limited to the standard Artist, Album, and Track names, your iPod is still using other tags like disc and track numbers and AlbumArtist for sorting.
You mention using Bluetooth, which means you must be using an iPod Touch. While there are several apps that will provide a solution for playing FLAC files locally, none of them will provide a direct path when connected to your car radio by USB. But they will work connected by Bluetooth. What you see on the display will still be limited to the tags that the car radio manufacturer has chosen to show. And it is highly likely the SD card or USB key playback will look pretty much the same.
Regardless, having a tag like AlbumArtist or anything else in your music files should not affect the performance of the iPod, the car player, or any other device. If they can't use a specific tag it is simply ignored. Other than embedded artwork, text tags take up little to no space compared to music even in the lossiest of files. So there isn't a space savings benefit to really compare.
But back to the original intent of your posted thread. If there is truly a difference of 60x as your test would indicate, perhaps this should be reconsidered by @Florian sometime. Maybe with the machines of today with faster processing power, the reasons for this difference in operation from the first design long ago are no longer necessary.
This looks like the action had nothing to remove and just ran without touching the files. If you use extended tags, the tag of each file is always written.
So when comparing performance, please make sure that all files are tagged with an album artist tag. I agree that there is a difference in performance, but not to this extent.
OK, this video was pretty impressive. Thanks for taking the time to create it.
I've revised the thread-locking strategy when writing tags to improve performance with Mp3tag v3.25h.
It would be great if you could test this version to see if the two methods (extended tags vs. actions) behave more similarly now.
It's working perfect now Florian! Thank you for making those revisions. I knew I should have just posted a video from the start, would have saved us all a lot of back and forth conversation. To be honest though, I'm surprised that this wasn't reported sooner. I bet most people probably don't realize there are multiple ways to do so some things and just get in the habit of using either the Quick Actions or Extended Tags and so they probably never noticed the difference. At least now I don't have to avoid using the Extended Tags panel anymore. It's very useful aside from the speed issue which thankfully isn't an issue anymore.
Thank you again for all the work you've done on this wonderful project.
Exactly. But I just read the changelog before editing lots of files and thought, hey what's that. Indeed it always took a looong time for me to edit some hundreds files, like deleting comments etc. I never tried to compare or noticed the speed difference between those methods. But now, WOW! Everything is so speedy! Thank you Florian!
That's why I said I was really surprised no one ever noticed this and/or reported this before. It's night and day difference now! I dreaded making minor changes to lots of files before only because I knew it was going to take forever and I'd have to sit and watch that "Writing Tags" bar write each file one by one. But not anymore! Works so much better now.
