Often I don't want (Remaster) or (Live) to remain in the title tag of my files. Removing those is easy with regex replace. I then rename all the songs via "convert -> tag-filename" to the pattern and folder structure of my choice.
Which leaves me with a bunch of .lrc files that have different names than the songs they belong to, breaking the connection between them.
I would love to be able to use mp3-tag to recognize when a song and an .lrc file have the same name and to link the .lrc file to the song, meaning when the song is renamed/moved through mp3-tag, the .lrc file gets renamed/moved as well and ends up in the same folder with the same name as the song it belongs to.
Is that possible? I've been moving and renaming .lrc files by hand for quite some time now and I'd love to be able to automate that step.
You could embed the external lyrics in a field like UNSYNCEDLYRICS or LYRICS.
Also, you could include the lrc-files as files that are also displayed in the files list and treat them there just like the audio files - if you modify the _FILENAME directly.
See File>Options>Tags which files are included in the files list.
I have now *jpg; *.png; *.pdf; *.txt; *lrc; in the list and they all apear.
All these filetypes naturally have no tags and only some columns (like a column for the filename) will show anything.
Maybe there is something wrong with your confugration file.
You can test it if you close Mp3Tag and rename the mp3tag.cfg-file in your %appdata%\Mp3Tag-folder so that Mp3Tag has to create a new cfg-file if you start it again. Later you can rename it back.
It works for CDG files.
[2020-11-22] NEW: CDG files are now renamed with corresponding FLAC files.
If you look at other threads in the forum that deal with lyrics in flac files then it always circles around embedding the lyrics.
And that works.
So it is up to your workflow to either keep the external files and loose the link occasionally or embed the data and get the full support in MP3tag.
If you shorten that to
Action -> Replace with regular expression
Field: _FILENAME
Regular expression: \s(\d{4}\sremaster)
Replace matches with:
The it takes any filename and removes the string described by the pattern.
I noticed this some years ago and so I expect this behaviour.
I don't know if this behaviour is intential, but I have no problem with it and take it as it is.
I did not take it in account for your problem because you wrote folder and not files:
If the regular expression does not find a match, it returns the input string.
If you modify your data with an action group you could call that modification with just a single step.
On a more philosophical side:
Separating data that really belongs together into several files proves to be a volatile step in the long run.
The forum is full of threads where pictures that have "always" been there, suddenly disappeared - because they were not embedded but files in the file system. And when the audio files got moved to different locations, the picture files usually stayed in the original place.
The same would apply to other files like e.g. the lyrics files.
The superior move for the covers is to embed them.
And I would think that the same applies to lyrics as well.
You can filter for files with lyrics,
you can sort by modification date.
And you don't have to leave MP3tag to delete the lyrics in a file when the lyrics are embedded in field.
OK. You know now the options that are currently available. It is up to you to adopt them or partially use them or cling to the customary workflow if you see too many obstacles for you.
It does not help you in this special case but you are not restricted to the content of the filename with non music files. There are other information tags like %_directory% or %_parent_directory%, which ie. would help if you have a folder-structure like me (%albumartist\%album%\). In fact I use these placeholders to rename downloaded booklet-pdfs with cryptical name to my naming scheme with an action of the type Format Value for _FILENAME and the format string: %_parent_directory% - %directory% - Booklet.pdf
There are even more options. So you could import the LRC-file with an action of the type "Import Textfile" to i.e. UNSYNCEDLYRICS and later export it to LRC again using the placeholders of your flac-file for the naming scheme.
Then there would be another very crazy method for which the idiom "from behind with the fist through the eye" would be used in Germany, namely by C&P of the entire tags:
Rename all LRC files to MP3, arrange these MP3 files in MP3Tag in the same order as the corresponding FLAC files, mark the FLAC files, press CTRL-C, mark the MP3 files, press CTRL-V. Your LRC files now have tags, which you can of course use to name the files. Then delete all tags in the MP3s and rename them back to LRC.
You could suggest this as an additional feature.
As long as there is no such feature I would adjust my workflow and use the already implimented feature to handle CDG-Files, rename the lrc-files to the extension cdg, i.e. with the DOS-command rename *.lrc *.cdg and later rename it back to lrc.
This may be if you do it album per album. But you could do the import for all your files in one go, later filter for %unsyncedyrics% PRESENT and export the lrc-files. And you can export them again and again if there are only made to the filenames.
Even if I want to depend on lrc-files I would keep the UNSYNCEDLYRICS-tagfield filled. Some redundancy can help sometimes and you can really neglect the extra-space for some text-bytes in contrast to high-resolution covers.
That can't hurt. Florian usually reads along, but it makes things easier for him on the administrative side if there is a separate thread, e.g. in the German "Vorschläge" section.
