Custom Naming

[garym]

Re: Custom Naming

@schmidj provides a great explanation (as usual). Another way I think about the [] in the naming string is thinking about computer programing using several "IF THEN DO, then END" indications. That is, code to say IF (something is true) THEN DO (some naming instructions), then END. For example, the [IF!COMP] is the "IF THEN DO" part, then it is followed by the info on what to do (how to name something. Then this "IF THEN" has to have an end. The [] is the "END" command. If you have nested "IF THEN" statements, then you need multiple END statements, thus sometimes seeing [][].

Regarding this issue, I think it was just sloppiness on my part in creating the string, but I was lucky that it didn't matter in this case and either happens to produce the right outcome, given where it is placed in the string..
[disc][].
[disc].[]

However, you should change "[disc][]." "to [disc].[]" to actually be correct.

[Spoon]

Re: Custom Naming

Help is also online:

https://www.dbpoweramp.com/Help/dMC/Naming.htm

[Supernaut]

Re: Custom Naming

For a better understanding of the string editing language used here to make the filenames, look in the dBpoweramp help file for custom naming.

Basically the [] serves as what we call a delimiter. It appears following commands in the string editor which require one or more expressions as input (following the command) to tell the parser (the part of the string editor which separates the commands) when the input for that command has ended. Since one can nest commands (as is done in your naming string}, if there is a [] after the first command before the second one, they are not nested but run consecutively in forming the string. If there is no [] before the second command the commands are nested and the second command executes as controlled by the first command. Then there might well be a [][] after the input for the second command to tell the parser that both commands have ended.

Thank you, @schmidj. I won't pretend that I'm ready to create my own strings from scratch, but I'm starting to get the gist of what all the individual commands mean. It all makes much more sense now than it did when I started a few weeks ago, and I'm extremely grateful for all the help available via this forum.

Another way I think about the [] in the naming string is thinking about computer programing using several "IF THEN DO, then END" indications. That is, code to say IF (something is true) THEN DO (some naming instructions), then END. For example, the [IF!COMP] is the "IF THEN DO" part, then it is followed by the info on what to do (how to name something. Then this "IF THEN" has to have an end. The [] is the "END" command. If you have nested "IF THEN" statements, then you need multiple END statements, thus sometimes seeing [][].

Regarding this issue, I think it was just sloppiness on my part in creating the string, but I was lucky that it didn't matter in this case and either happens to produce the right outcome, given where it is placed in the string..
[disc][].
[disc].[]

However, you should change "[disc][]." "to [disc].[]" to actually be correct.

Brilliant, @garym! All of your advice has been invaluable. I'll alter the string accordingly and double check everything is as it should be before I get down to the task of ripping my CD collection.

For a better understanding of the string editing language used here to make the filenames, look in the dBpoweramp help file for custom naming.

Help is also online:

https://www.dbpoweramp.com/Help/dMC/Naming.htm

Yes, thank you both @schmidj and @Spoon. I did read through the Naming guide but got a bit lost having very little knowledge of the subject. Again, it all makes much more sense now and will hopefully all become easier to understand with time (although I think I understand enough now to just "set it and forget it").

I do still have one more question about the naming string, although it just to satisfy my interest and not really technical.

Is the naming string basically just another tool used for ripping CDs (in the same way as a disc drive, for example), or are the details of the string stored in the file somewhere (i.e. like tags)? To put it another way, if I were to use two completely different strings to produce a file with exactly the same name (for example, the default naming string and something similar to string described above), would the details of which string was used be recorded in the resulting file?

[Spoon]

Re: Custom Naming

The naming string is not stored in the files.

[Supernaut]

Re: Custom Naming

I posted a reply to this thread two days ago, but it still isn't showing. Could admin please check posts for moderation to see where it is? Thank you.

[Supernaut]

Re: Custom Naming

The naming string is not stored in the files.

OK, thank you.

[garym]

Re: Custom Naming

OK, thank you.

That said, you can save the "profile" name as a tag when ripping. If you use different naming strings for different ripping profiles, that would provide that info. But to be honest, I can't imagine why this info would be useful after the fact.

[schmidj]

Re: Custom Naming

I've saved my naming strings and other settings as a text file, so I have them in the event I need to reinstall. Very useful when I switch to a newer computer.

[garym]

Re: Custom Naming

I've saved my naming strings and other settings as a text file, so I have them in the event I need to reinstall. Very useful when I switch to a newer computer.

Yes! That I do as well.

[Supernaut]

Re: Custom Naming

That said, you can save the "profile" name as a tag when ripping. If you use different naming strings for different ripping profiles, that would provide that info. But to be honest, I can't imagine why this info would be useful after the fact.

I've saved my naming strings and other settings as a text file, so I have them in the event I need to reinstall. Very useful when I switch to a newer computer.

Yes! That I do as well.

Thank you for clarifying that for me. I also have the naming strings saved in a separate file, so I won't be saving them as a "profile" tag. Still, it's interesting to know that even though the naming string isn't saved as part of the file, there is a way to save it as a tag if desired. Seems like everything is possible!

As per the advice given earlier in this thread I've amended the string I was using (changed "[disc][]." "to [disc].[]") so that it now looks like this:

[MAXLENGTH]240,[IFCOMP]Various Artists\[album]\[IFMULTI][disc].[][track] - [title][][IF!COMP][IFVALUE]album artist,[album artist],[artist][]\[album]\[IFMULTI][disc].[][track] - [title][][]

I think everything is in order, but I've posted it here just to make sure and in case anyone else wants to copy it. Also, here is the same string but with the artist included in the file name:

[MAXLENGTH]240,[IFCOMP]Various Artists\[album]\[IFMULTI][disc].[][track] - [title] - [artist][][IF!COMP][IFVALUE]album artist,[album artist],[artist][]\[album]\[IFMULTI][disc].[][track] - [title][][]

I did try using this longer string (artist included), but found that it sometimes produces slightly peculiar results (see track 08 in the attachment below).



I imagine that this naming string would also produce very long file names for any kind of classical compilation, not that I have many of those in my collection. Seeing as both strings produce the same file name for non-compilation albums, whichever I use won't make a difference most of the time.

[garym]

Re: Custom Naming

Thank you for clarifying that for me. I also have the naming strings saved in a separate file, so I won't be saving them as a "profile" tag. Still, it's interesting to know that even though the naming string isn't saved as part of the file, there is a way to save it as a tag if desired. Seems like everything is possible!

No, that's not what I meant. You can't save the naming string itself in a tag, and the string is not saved in the PROFILE tag metadata. Only the name of the Profile (for me, for example, the profile name might be "Home" vs "Office" so I'll know what setup I used to rip CD. Others might have a different setup, including naming string for "Classical" vs "Popular", etc. And the profile tag would simply say "Classical" or "Popular". It wouldn't contain any detailed settings.

I think everything is in order, but I've posted it here just to make sure and in case anyone else wants to copy it. Also, here is the same string but with the artist included in the file name:
I did try using this longer string (artist included), but found that it sometimes produces slightly peculiar results (see track 08 in the attachment below).
I imagine that this naming string would also produce very long file names for any kind of classical compilation, not that I have many of those in my collection. Seeing as both strings produce the same file name for non-compilation albums, whichever I use won't make a difference most of the time.

In my naming string ARTIST is *only* added to the file name in the case of compilation CDs. With single artist CDs, artist name is not appended to the file name. That's just a personal preference for me. And yes, with artist name as part of file name, one could get some very long file names. Although not terribly long with the use of the [MAXLENGTH] command in the naming string.

[Supernaut]

Re: Custom Naming

No, that's not what I meant. You can't save the naming string itself in a tag, and the string is not saved in the PROFILE tag metadata. Only the name of the Profile (for me, for example, the profile name might be "Home" vs "Office" so I'll know what setup I used to rip CD. Others might have a different setup, including naming string for "Classical" vs "Popular", etc. And the profile tag would simply say "Classical" or "Popular". It wouldn't contain any detailed settings.

OK, I see what you mean now.

In my naming string ARTIST is *only* added to the file name in the case of compilation CDs. With single artist CDs, artist name is not appended to the file name.

I understand, which is why I said that it won’t make a difference which string I use most of the time. Both strings will produce the exact same file name for the majority of the CDs in my collection (i.e. non-compilations).

Edit: At least that’s what they should do if I’ve edited them correctly!

One more question I have regarding saving multi-disc CDs to the same folder. When the second disc is ripped, does the artwork file (e.g. cover.jpg) automatically write over the file saved when the first CD was ripped? It appears that this is what happens, as there is only one artwork file saved in the folder after ripping both CDs.

[garym]

Re: Custom Naming

One more question I have regarding saving multi-disc CDs to the same folder. When the second disc is ripped, does the artwork file (e.g. cover.jpg) automatically write over the file saved when the first CD was ripped? It appears that this is what happens, as there is only one artwork file saved in the folder after ripping both CDs.

Yes. Which is one of the reasons that my setup has each disc of a multidisc CD in it's own subdirectory, under the top "Album name" subdirectory. Then I can have different art for each disc if I want.

edit: of course you can also do this if you embed the artwork in each file rather than, or in addition to, using folder.jpg or cover.jpg.

[Supernaut]

Re: Custom Naming

Thank you, @garym.

[Supernaut]

Re: Custom Naming

Yes. Which is one of the reasons that my setup has each disc of a multidisc CD in it's own subdirectory, under the top "Album name" subdirectory. Then I can have different art for each disc if I want.

This is something I meant to ask about. When the individual discs each have their own folder under the Album parent folder, they are simply labelled “Disc 1”, “Disc 2”, “Disc 3”, etc. The album name is not included in these subfolder names. I had thought that folder names somehow helped the music player create a path to find files within a directory, and that having folders with the same name anywhere in the directory posed the risk of a mix-up somewhere along the line.

However, after experimenting with different naming strings and different settings in different software, I can now see that the file metadata is what’s important. As long as the top layers of the directory are specified (e.g. Music > Lossless), all files in that directory will be found and displayed correctly regardless of the subdirectory folder names, as long as the file metadata is in place.

Obviously, having the folders organised in an easy to navigate manner makes everything look nice and is user friendly, but it isn’t actually necessary for the software to find the files. So having numerous folders saved with the same name (e.g. “Disc 1”, “Disc 2”, “Disc 3”, etc.) within the various subdirectories will not cause any problems.

I thinks that makes sense, but if I’ve got it all wrong then please let me know!