Because I'm usually working on my whole library at once in MP3tag (thousands of files) it would be nice if the current highlighted file were still highlighted (and shown in the current pane) after Refresh File View instead of the list reverting to start with the first file in the current sort sequence. I'm using MP3tag to add back tags that have been lost when a file is saved in Audacity. I know this is just a work-around for an Audacity bug, not an MP3tag bug, but MP3tag could make my task easier if the orginally-highlighted file was still highlghted after a refresh, so I didn't need to scroll through my long list of files.
I am not quite sure why you need to refresh the file list ...
Ctrl-T re-reads the tags.
Also, missing fields could be filtered with
MISSING
F3 toggles the filter.
I would assume that either the list is then reduced to a handlable amount of files in which a particular file could easily be found or that it is not necesary to select one particular file all the time.
Please not also, that if you modify the data it could be that the previously selected file is not included in the re-read list.
I need to refresh the file list because when I have edited the file in Audacity I filed it with a new name (added -a to the filename) because I need to keep the new and old copy - the old copy has the tags I need to re-add to the new copy. Otherwise if I file the edited file with the same name in Audacity the tags are lost. I know the previously selected file might not be there any more, but if it is, I want to go straight to it to get the tags Audacity has lost.
Isn't this a question of workflow - e.g. yu could select all the files that you want to treat even in MP3tag, then copy all of them to a new folder, edit files in Audacity, if this is mandatory (I am pretty sure there are other editors around that keep the tag data), then copy the tag from the still loaded old file and paste them to the new file ...
You could even save work if you have the same order of files in the source and the target location, you could copy and paste all the tags from all the files in 1 go instead of doing that individually file by file.
I mention all this as I am not sure when your request will become a feature. So, all these steps and functions could serve as a workaround until then.
And these steps are under your direct control and you don't have to wait until somebody else becomes active.
Copying all the files I want to change into new folders is more work than scrolling down a list after Refresh because they are not all in the same folder to start with so I would need to create muliple folders to avoid having to try to work out which folder each new file belongs in when I copy back. I wasn't aware I could copy a file to a new folder in MP3tag - can you tell me where is that function?
Alternatively, perhaps you can point to one of the other music editors you know about which don't lose tag data (obviously they need to be free to use like Audacity and have similar functionality).
Anyway, I thought it would be simple for MP3tag to remember the current file and keep it hightlighted in Refresh (it does this for other functions, e.g. Sort). I guess it must be more difficult than that.
See Edit>Copy ...
This copies (initially) all the selected files to the selected folder - but if you use either Convert>Tag-Filename to create a folder structure based on tags or the equivalent as an action, you will find a copy of the previous structure (if that was also based on tag data).
Also, you could setup an action that copies the original path into a user-defined field and then, after you have copied the original data to the new file, you could move that file to the original location ...
There are so many ways to get the final result that do not need a highlighted file.
Doesn't the Nero Wave editor remember tags?
In my workflow I first edit the audio part and make sure that is AOK and then I add tags.
If you edit one file at a time, you could copy the tag data in MP3tag, edit that very same file in Audacity without the need to create a copy, re-read in MP3tag and paste the tag data from the clipboard (provided on other application has used the clipboard).
As I said: it so much down to your workflow.
Which file-format are we talking about? WAVE?
filetype is MP3 - Audacity loses album art (cover type in MP3 = front cover or artist), and blanks Discnumber and Album Artist but retains all other fields such as Project and Contributing Artists
Yes, as I am generally only editing the waveform shape in Audacity then copying the tag data is probably the best solution, although in an ideal world I still think MP3tag should respect the "current file is displayed after an action".
Thanks also for the idea of using Convert>Tag-Filename to move a file to a new directory - I hadn't realised MP3tag would do this, although it now seems obvious. This will enable me to arrange songs by genre.
Thanks again, problem solved.
This looks to me like your Audacity only write ID3V1 tags - I think there are settings in Audacity that manage this behaviour.
https://wikieducator.org/Using_Audacity/Editing_ID3_Tags
After saving with Audacity, MP3tag reports the tag as ID3v2.3 (ID3v2.3). After adding the cover art back, MP3tag reports the tag data as ID3v2.3 (ID3v1 ID3v2.3 APEv2). I've been using Audacity 3.0.2 but I just tried 3.2.1 which has the same problem.
I note that Metadata Tags Editor - Audacity Manual says "For both MP3 and MP2, only ID3v2.3 tags are exported. ID3v1 can be exported using [Cmd-line export]" so I think it's just an Audacity bug that it drops the cover art and other tag fields.
Incidentally, the wikieducator page you refer to says says to use File --> Open Metadata Editor but the File menu on Audacity 3.0.2 and 3.2.1 doesn't have File>Open Metadata Editor, only File>New, Open, Recent Files, Close, Save Project, Export, Import, Page Setup, Print Exit. Do you think maybe the wikieducator page could be out of date or wrong? There is an Edit>Metadata function but it doesn't allow the user to change the tag verson.
Could you check whether the missing data is still in the APE tags?
Go to File>Options>Tags>Mpeg and set APE also to read.
then re-read such a file and see if some more data shows up.
Or the other way round (although then APE should be shown as first tag version) switch off the reading of APE tags and see whether that helps.
After downloading the newest portable version, I understand the function like this:
You edit a WAV in Audacity and you add the metadata in Audacity Metadata Editor you can export your WAV into another format like MP3.
If you choose FILE -> Export -> Mp3 you will be asked, if you want to save the metadata in such a format.
Example for added Metadata in Audacity:
After an export into MP3 and loading this mp3 into Mp3tag, the Metadata looks like this:
I have no idea, why the COMMENT and YEAR tag will be doubled by such an export.
Thats how the 2 x COMM and TYER and TDRC looks like:
This has been a common Audacity reported issue that we have seen here previously. I have had this happen myself and cannot confirm why, when only one date has been written in Audacity.
interesting but I'm not editing WAV files LyricsLover
It looks like Audacity writes the same Year "2022" once as TYER and once as TDRC.
It doesn't matter what format this starts in, as Audacity converts to work in PCM AFAIK.
Options>Tags>Mpeg APE was off. setting it on and re-reading, only the file edited with Audacity showed any tag fields at all. Setting APE off again restored the tag fields in the non-Audacity files and the Audacity-edited files were still wrong. I still think Audacity is dropping the data. I have a work-around and it's not MP3tag that's broken, so let's forget it.
You are right, Audacity itselfs know this issues:
There are at least two more issues: 1696 and 1464
You can find the problem for the doubled YEAR here in the export source code:
else if (n.CmpNoCase(TAG_YEAR) == 0) {
// LLL: Some apps do not like the newer frame ID (ID3_FRAME_YEAR),
// so we add old one as well.
AddFrame(tp.get(), n, v, "TYER");
name = ID3_FRAME_YEAR;
}
After Line 2217 you also find the reason, why the COMM will be doubled, caused by a "ugly iTunes hack":