[Suggestion] Tagging files based on filepath using the placeholder format

[joex92]

Is your feature request related to a problem? Please describe. I have some old song files that I want to convert from different artists and albums that are on their artist's folders and album's folders, etc. Organized. BUT they have no ID Tags, and there are a lot of song files, so doing it manually it's a pain.

Describe the solution you'd like I came up with 2 solutions:

I just saw how the <> placeholders work for the output file's name format, specially the <directory> placeholder. I believe that placeholder could be useful to use on the Show title info section, for example to get the 2nd subfolder name on the full path as the artist and the 3rd subfolder name as the album. For example like this: and then you do "use for all selected" and then all selected tracks names would change accordingly.

Another solution is adding a format pattern for this option: using placeholders for any tags... this way users could type their own RegEx pattern for the tags... for example:

/.*(?<artist>.*)[\\\/](?<album>.*)[\\\/](?<title>.*)\.(?<extension>.*)/

It would look something like this: so this would get the artist, album and title from the full path... in this case you should add all the variables names for any tag (or the common ones).

either one of these or maybe both solutions, for both beginners and advanced users....

Describe alternatives you've considered other than doing it manually, I don't know how to do it faster.

[joex92]

If there's already a way, idk where to look that for... I was hoping to find some "documentation" page or something like that...

[Lee-Carre]

Until I got down to

get the artist, album and title from the full path

I was very unclear as to the problem you are trying to solve.

If my understanding is now accurate, then this might be beyond the scope of Fre:AC (I'll leave that up to enzo1982, to decide).

If you already have audio files, which simply lack metadata tagging, then I would recommend you use MusicBrainz Picard (or similar). For Picard, the following steps are relevant:

1. have Picard load the relevant files in order to work on them
2. have Picard generate an AcousticID fingerprint (a signature based on the waveform, to my understanding of it; akin to a hash-digest) — select the relevant files, and perform key-combo Control+Shift+Y
3. have Picard Scan (Control+Y) the MusicBrainz database for matches — ensuring that you've found the right match will be the tricky part; you may need to tweak configuration parameters, or possibly add the release (CD or vinyl, or whatever medium the files were genereted from) to MB's DB, if it's missing
4. once the correct match has been found, then it's easy to save the other metadata into the file's tags — this can, indeed, be done in batch/bulk (an entire album at once), rather than have to be repeated per-(track|file); though you may also tweak things to your liking, per-file, if you wish

[Lee-Carre]

Meta: I would suggest/request that the title of this issue be renamed (find the Edit button, up top) to something more like

Tagging files based on filename

I had no idea what “Placeholders on tags” meant.

[joex92]

I have a ton of audio files from way back when I never knew about tags, so I used to just rip the music from CDs and store it on folders... the thing is that it would be good to either get the tags from the filename or being able to use a placeholder to get the folders name in the filepath... not everytime music files are usually stored as artist\album\song.ext, sometimes there might be an album with various artists with the artist in the file name, not in the folder name, like this album\artist - song.ext... so being able to use regex or placeholders would be better, like having more control over what to use from the filename and/or filepath...

I'm going to try Picard, but I don't like using multiple softwares for similar means...

[Lee-Carre]

I have a ton of audio files from way back when I never knew about tags, […]

Sounds very much like Picard (or similar) is what you need.

I'm going to try Picard, but I don't like using multiple softwares for similar means…

Well, expecting one piece of software to do everything brings many problems. The complexity soars, and the quality plumets. It's much better to use a set of tools, each of which is (relatively) small, does one job, but does that one job well; to achieve greater effect, use them in combination. Think of it like a traditional toolbox; there isn't one tool to do everything, but many different specialised tools. Many tasks require more than one tool.

Picard and Fre:AC are for different tasks, and focus on different priorities.

Fre:AC is for extracting CDDA, and transcoding between audio formats. It happens to have some tagging features, in order to make that extraction/transcoding process better; so that files are named something sensible (based on the metadata), and at least basic metadata may be tagged when generating files.

However, Fre:AC isn't a generalised metadata editor. Expecting it to be one, isn't wise for many reasons.

Picard, on the other hand, is very much about editing and otherwise managing tags, and a whole library of audio, and brings many benefits.

The two aren't competitors, they complement each other.

There's no point in Fre:AC trying to replicate what Picard already does, or otherwise trying to achieve parity with it.

A screw-driver and a chisel are both metallic tools with a handle, and similar shapes (a long, flat(-ish) piece of metal (at the business end)). However, they're used very differently. Trying to use either, for the other's role, won't work well. Same here between Fre:AC and Picard.

Give Picard a try, it works well. I think you'll like it; especially that it can recognise music tracks even without any tags (based on the AcoustID), and look that up on MusicBrainz to (if a match is found) populate a whole bunch of metadata for you. That sounds like just what you need, for an existing/old, untagged music library.

Fre:AC is more about tagging tracks, or a whole album at most. But, isn't designed to tag an entire library. Picard, however, is designed to handle large libraries, and mass re-tagging in bulk, with ease. Picard has extensive documentation, too, and is well maintained (frequently updated). The MusicBrainz DB is also well-tended by many contributors (but, since it sounds like you have a large collection, you might well have some albums (or pressings/editions) which aren't in the DB; so please do add them).

Might I also suggest, depending what format the files are, re-encoding it using a modern codec. I would recommend FLAC (if your source is lossless, otherwise Opus).

If you want/need further guidance, feel free to ask. Though, the discussions section is likely better suited for general advice (rather than tickets which are for bug reports and feature-requests).

[joex92]

Oh ok... I'm not used to discussion boards in GitHub, not every project has a discussion board so I'm more used to the issue tickets instead... Also I thought it was somehow a good adittion...

Thanks for the explanation, but I'll let Enzo decide on this ticket or any other Dev that can make changes on tickets...

[Lee-Carre]

I'm not used to discussion boards in GitHub, not every project has a discussion board so I'm more used to the issue tickets instead…

Yes, they're a newer feature (while tickets are a long-standing feature). I think that each project must manually enable discussions, if it so chooses (opt-in).

Part of why the feature came about, was to separate tickets (bugs & feature-proposals) from other types of exchanges which are still relevant to the project (like in this case, which is more about usage/work-flow, rather than a technical problem per se). Like with Fre:AC versus Picard; each is for a different purpose.

Also I thought it was somehow a good ad[d]ittion…

I completely see where the idea came from, yes. Hence responding to it, seriously. But, I'm addressing your goal, rather than presumed next step. Plus, explaining the problems/considerations of the nature of your suggestion/proposal/request, having relevant insight.

Ultimately, it's for enzo1982 to decide. I just happen to know that he's busy with other things in his life, lately, and (unfortunately) doesn't have a whole lot of time to develop Fre:AC, at the moment. So, I thought I'd give some input, and a suggestion (Picard), instead of leaving you hanging with silence. I sympathised, knew of a sensible suggestion which would help greatly, and felt like helping out. Consider it a form of contributing to the project, in a way other than code development. That's part of what libre projects are about; a community of users helping each other solve problems. That includes if someone's taking a questionable approach to solving a problem (and/or hitting a road-block because of it).

I'll let Enzo decide on this ticket or any other Dev that can make changes on tickets

Indeed. It's possible for repository admins to move tickets (between repos) and/or transform tickets into discussions.