I would like to batch remove id3v1 tags from mp3's stored on a network drive. I have a mixture of FLAC/MP4/MP3 files, some 15K music files in total. It is not practical more me to load then entire 15K library into mp3tag, and then subsequently filter out the mp3's.
The networked drive is mapped to macos via SMB.
Is it possible to open a top-level networked music folder, and have mp3tag only load the mp3's that contain id3v1 tags?
You can use the search feature in windows for only files with the extension mp3. Select all (Ctrl-A) then right click these and open with mp3tag. You will then have only a list of all mp3 based files open.
But as these are on a network drive, expect it to take longer to action than if they were on a local drive.
I have yet to find a way to search for *.mp3 (or any extension based search) on a mapped network drive in macOS. The network drive is mapped to macOS via SMB (it's a Synology NAS, with SMB file service).
I think my library is large enough, that I'd like to only find and load mp3's with id3v1 tags??
A solution at minimum needs to filter mp3's at the operating system level, yes. However, if the library is large enough, then loading say 10,000 MP3's all at once may not be practical, and that's why I was asking of the possibility of only loading mp3's into mp3tag that contain any id3v1 tags?
And for that purpose each file has to be opened and then someone has to decide whether the current file contains id3V1 tags or not.
I am afraid there is no way around loading all the files - or finding an OS way to get a filtered list.
On macos 12.3.1, I've found that you can search a mapped network share (or any folder, indexed or not, local or on the network) with the spotlight search query "kind:mp3".
From within Mp3tag, if I do File->Open, with search parameter of "kind:mp3" on the mapped network SMB share, then Activity Monitor goes to 100% on both "Mp3tag", and "com.apple.appkit.xpc.openAndSavePanelService (Mp3tag)", and just stalls (I let it run for about 10 minutes, and then just cancelled).
In macos finder doing the same "kind:mp3" search yields ~5K results, takes about a minute to run, but doesn't stall like Mp3tag is doing. I also haven't been able to successfully drag/drop the finder's found mp3 list into mp3tag. For whatever reason, selecting all of the found files from within finder, and right-clicking, I'm not able to select the typical "Services"->"Open in Mp3tag". The context menu to launch Mp3tag from the file selection is just not available.
On a local drive with Windows, my library of 24k+ files takes about 2 minutes to scan and open the first time. But with the library function in mp3tag enabled, this is shortened to just a few seconds now. Again with a network drive this could add to these times.
Once you have them all open in mp3tag, you can simply apply a filter and look for the %_extension% mp3.
There are some differences, based on the OS capabilities and functions. I know the new MacOS version was built from the ground up, and thus became a paid-for app. As can be expected, there will be some limitations with one version versus the other.
The documented available features are already found here.
Ended up doing the suggested Cmd-O in Mp3tag, selecting top level SMB networked/mapped folder containing all music files, waiting about 10 minutes for the ~15K files to load (very slow even over 1 Gbps network to NAS), filtering out the ID3v1 tagged files with %_tag% HAS “id3v1”, and doing a Cmd-X, Cmd-V (Cut/Paste) on all filtered MP3’s. The Mp3tag options/preferences need to be set so that ID3v1/ID3v2 are both read, but only ID3v2 are written. Finally have all ID3v1 tags removed from MP3’s!
I think that this is a fairly normal speed. Divide 1Gbps by 10 to get the number of Bytes per second (under ideal conditions) and then set that number in relation to the number of bytes in the files and you have an idea how long it will take.
Accessing a network drive is the second slowest approach for most, slower is only the access to cloud services over the internet.
Yet, the library was introduced maninly for the Windows version to overcome memory limitations when loading large libraries. I doubt that a Mac has those shortcomings as the Mac version most likely is no 32-bit application - as @MotleyG said: MP3tag for Mac is all new.
In this particular case I doubt that a Windows version would have loaded the files much quicker.
If you set the options to only read and delete V1 and switch all other options for tags off, then you can simply cut the tags with Cmd-X. Then you don't need Cmd-V. You have to re-read the tags, though, once you have reset the tag options to the preferred handling (probably: read for V1&V2, Write V2UTF-16, Delete V1,APE,V2).