Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SilverLitz]

Is there a setting to have MC add a 2 digit track number to the beginning of the track file name?

iTunes seems to do this automatically when ripping, but my MC rips have not done it, and therefore the music order is incorrect in the file structure.

[MrC]

If you have [Track #] as a filename component under your File Locations > Audio > Filename rule, you should already get this.

[SilverLitz]

If you have [Track #] as a filename component under your File Locations > Audio > Filename rule, you should already get this.

Thanks!
I wish I knew that before ripping 100's of discs.

I would suggest that be the default.

[MrC]

It's no problem.  You can change them all with the Rename tool (which can use the same rules).  it will pad out the track numbers likewise.

Select your files, and you can see how the Rename tool will take care of the job.  Test on a few first to be sure your rules are correct.

[SilverLitz]

It's no problem.  You can change them all with the Rename tool (which can use the same rules).  it will pad out the track numbers likewise.

Select your files, and you can see how the Rename tool will take care of the job.  Test on a few first to be sure your rules are correct.

Great!  That will save many hours of manually renaming in Explorer.

Can I get Rename to change just the filename, not the file structure location, as I have had to manually move folders around in Explorer to get a more logical and streamlined organization?  This is especially the case with Classical.

[SilverLitz]

MC does not seem to recognize the major changes I made in the File Structure. 

When I look under "Files" in the left pane, it is still showing the structure that MC originally ripped into, NOT the actual current structure after the changes I made using Windows File Explorer.

[MrC]

Can I get Rename to change just the filename, not the file structure location, as I have had to manually move folders around in Explorer to get a more logical and streamlined organization?  This is especially the case with Classical.

Yes, look at the tool.  It shows you that you can enable Directories, Filename and/or Find & Replace sections independently.

As you a) learn how to use the expression language, and b) settle your file system naming structure, you can put together an expression that works for renaming and all newly created files.  Take a look at the Preset... button at the bottom of the rename tool.  Until you build up that uber-path expression, create presets for your media types.

[MrC]

MC does not seem to recognize the major changes I made in the File Structure. 

When I look under "Files" in the left pane, it is still showing the structure that MC originally ripped into, NOT the actual current structure after the changes I made using Windows File Explorer.

Do you have MC's auto-import running on the paths where you've made changes?  Is Fix broken links enabled?  Otherwise, changes you make in Explorer can't get noticed.

[SilverLitz]

It's no problem.  You can change them all with the Rename tool (which can use the same rules).  it will pad out the track numbers likewise.

Select your files, and you can see how the Rename tool will take care of the job.  Test on a few first to be sure your rules are correct.

I tested this out on a couple of albums, and after some trial/error, I thought I got it to work as I want, by unselecting the Directories box, and checking the Filename box with the  [Track #] - [Name] rule.

There was still the strange problem of MC not seeing my current folder locations (moved files using Windows File Explorer), but seeing the albums in the folder it originally ripped them in (that no longer exist).

So I selected All the files on the NAS to be Renamed, and to my horror it undid the Track#'s on the ~500 iTunes albums (which had the correct Track#'s), replacing the #'s with all "00".  Upon a limited spot check MC seemed to make the changes on the MC ripped albums.  Resulting in more damage than correction!

[MrC]

The Preview window will show you the resulting renamed files.  Did they show the track numbers?  These come directly from MC's [Track #] field.  Did you have a space in between the k and the # characters?  Are the [Track #] values correct for these albums?

MC's auto-import relies on certain change notifications being delivered from Windows.  Some NAS' don't support these file system change notifications.  Nontheless, re-running auto-import should detect the moved files, so long as they are under the same generally parent folder.  If files are moved outside of MC's watched folders, you'll have to reimport.

[SilverLitz]

Do you have MC's auto-import running on the paths where you've made changes?  Is Fix broken links enabled?  Otherwise, changes you make in Explorer can't get noticed.

YES,
MC's auto-import running on \\NSA320\music\ , all my folders are directories/subdirectories/... off this drive.

Fix broken links is "Yes (protected files on missing drives)"

[SilverLitz]

YES,
MC's auto-import running on \\NSA320\music\ , all my folders are directories/subdirectories/... off this drive.

Fix broken links is "Yes (protected files on missing drives)"

Changed:
Fix broken links is "Yes"

It seems to have the new locations, but also seems to show the old locations as well, but in the 1st column (cover art) it now shows a red "X".  Is there a setting to make the old locations disappear?  Or do I have to manually delete each?

[SilverLitz]

I tested this out on a couple of albums, and after some trial/error, I thought I got it to work as I want, by unselecting the Directories box, and checking the Filename box with the  [Track #] - [Name] rule.

There was still the strange problem of MC not seeing my current folder locations (moved files using Windows File Explorer), but seeing the albums in the folder it originally ripped them in (that no longer exist).

So I selected All the files on the NAS to be Renamed, and to my horror it undid the Track#'s on the ~500 iTunes albums (which had the correct Track#'s), replacing the #'s with all "00".  Upon a limited spot check MC seemed to make the changes on the MC ripped albums.  Resulting in more damage than correction!

It is worse than I originally suspected, MC did NOT insert the Track#'s on all the MC ripped albums, it only performed the operation on the albums that had not been moved in the folder structure.  But it seemed to wipe out ALL the Track#'s (replace w/ "00") on  ~500 iTunes albums (which had the correct Track#'s). 

MC code logic is definitely faulty in this instance, it should either sense the leading numerical or if it does not have the Track#'s in its DB and do nothing (cause no harm).

Is there a way to correct this with manually inserting the Track#'s or spending a couple of weeks re-ripping these albums using MC?

[MrC]

It isn't clear to me which operations you performed, and in which order.

You mention "MC ripped" albums, and that there were no track numbers.  Are you saying that your track numbers as seen by MC were all filled and valid?

It almost sounds like you're saying MC had valid track #'s but wiped those out when you renamed, and this doesn't make sense.

Keep in mind the distinction between file names, and MC's metadata and file tag values.  MC operates using its metadata.

Perhaps read the first couple of sections here:

   http://wiki.jriver.com/index.php/File_Properties_%28tags%29

[SilverLitz]

It isn't clear to me which operations you performed, and in which order.

You mention "MC ripped" albums, and that there were no track numbers.  Are you saying that your track numbers as seen by MC were all filled and valid?

It almost sounds like you're saying MC had valid track #'s but wiped those out when you renamed, and this doesn't make sense.

Keep in mind the distinction between file names, and MC's metadata and file tag values.  MC operates using its metadata.

Perhaps read the first couple of sections here:

   http://wiki.jriver.com/index.php/File_Properties_%28tags%29

MC wiped out the Track# in the filename of all my iTunes ripped albums, replacing the correct Track# with "00" in the filename.  It added the Track# as expected to the filenames  of the MC ripped albums that had not been moved in the folder structure, but did nothing to the MC ripped albums that had been moved.

[JimH]

Doubtful.  MC won't replace your track numbers unless you tell it to.  They're probably not in the Track # tag in the original file.  It is probably named something else.

[SilverLitz]

Doubtful.  MC won't replace your track numbers unless you tell it to.  They're probably not in the Track # tag in the original file.  It is probably named something else.

But MC DID, not theoretically, but ACTUALLY! 

These were 100's of album's previously ripped by iTunes that Track# in the filename, as I was trying to get MC do the same for earlier MC ripped albums, using the Renaming tool.  Since the albums in question were AutoImported and not originally ripped by MC, it seems the MC does NOT see their Track# in the albums metadata (blanks in Track# column), but seemed to differentiate between the Track# and Name in the filename, as deleted the leading iTunes ripped Track# to replace with "00".

[MrC]

You're describing that MC worked as I've mentioned above.  You used the Rename tool, telling it to use the [Track #] field, when those values were invalid or not present.

In the future, grab the track number from the file name using the Fill properties from filename tool, so that MC has valid metadata.

MC can under some circumstances derive these values for you during Import.

[SilverLitz]

Suggestion:
MC needs to differentiate the Track#'s in filename for multiple disc albums, to something like: 01-03 (for disc1 track3).  This way when the multiple discs are merged into a single folder, the order is still correct.

[MrC]

MC already uses Disc # and Track # in sorting.

Use the File properties from filename tool to grab both Disc # and Track #, in your case, using the partial filename template:

   [Disc #]-[Track #] ....


Perhaps [Name] follows where the ellipses are shown.

[SilverLitz]

You're describing that MC worked as I've mentioned above.  You used the Rename tool, telling it to use the [Track #] field, when those values were invalid or not present.

In the future, grab the track number from the file name using the Fill properties from filename tool, so that MC has valid metadata.

MC can under some circumstances derive these values for you during Import.

It is still does not make sense that MC eliminated the 1st two numbers of the iTunes Filename, without any Track # metadata, it would seem more logical that MC would assume the leading numbers were part of Name.

It is still faulty programming logic to perform an operation using invalid data; MC should know by the absence of Track # field values, that the values were invalid.  Blanks would NEVER be a valid Track #.

[MrC]

Your thinking on this is aligned with your feelings about the matter, but not in accordance with the facts.  :-)

Think about it - what is the track number of these (actual) track names:

   3 Minute Traffic Jam
   1 2 3
   2 Forms of Anger
   2 Hillcrest
   01 29
   3.2 Bedrock
   3:19 Intro

These track names begin with numbers.  Which are correct?  Hint: only 1 of 7 is correct.

MC did not eliminate the first two numbers.  You did, by telling MC to rename the files according to a template.

The lack of field values is insufficient as a criteria for deciding not to use the template.  There are perfectly valid, ordinary rules for writing out file names or file paths when certain fields are empty, such as Disc #.  My templates use Disc # to specify the folder names, but most of the time Disc # is empty.  So my rules must accommodate this.

[SilverLitz]

Your thinking on this is aligned with your feelings about the matter, but not in accordance with the facts.  :-)

Think about it - what is the track number of these (actual) track names:

   3 Minute Traffic Jam
   1 2 3
   2 Forms of Anger
   2 Hillcrest
   01 29
   3.2 Bedrock
   3:19 Intro

These track names begin with numbers.  Which are correct?  Hint: only 1 of 7 is correct.

MC did not eliminate the first two numbers.  You did, by telling MC to rename the files according to a template.

The lack of field values is insufficient as a criteria for deciding not to use the template.  There are perfectly valid, ordinary rules for writing out file names or file paths when certain fields are empty, such as Disc #.  My templates use Disc # to specify the folder names, but most of the time Disc # is empty.  So my rules must accommodate this.

It could be completely valid for a track name to have any combination of numbers in its name; that would be up to the artist.   Without other info, such as Track# metadata field,  MC should not make any assumptions.

Following is an actual example of what happened.  This was iTunes ripped album, and therefore MC did not have the metadata.

This was the album before the MC Rename (taken from back-up drive):
01 Shine On You Crazy Diamond (Parts 1-5)
02 Welcome To The Machine
03 Have A Cigar
04 Wish You Were Here
05 Shine On You Crazy Diamond (Parts 6-9)

This was the album after the MC Rename:
00 - A Cigar
00 - On You Crazy Diamond (Parts (1)
00 - On You Crazy Diamond (Parts
00 - To The Machine
00 - You Were Here

Without Track# metadata, it would seem logical, that the following COULD have been the result, but was NOT:
00 - 01 Shine On You Crazy Diamond (Parts 1-5)
00 - 02 Welcome To The Machine
00 - 03 Have A Cigar
00 - 04 Wish You Were Here
00 - 05 Shine On You Crazy Diamond (Parts 6-9)

Before I ran the Rename on my entire library, I performed limited checking of how MC's Rename tool behaved, and I noticed that it did NOT double up the Track# on albums that already had that convention (but these were albums that were MC ripped), but on those albums the Rename operation was not performed.  I erroneously assumed that would be the case with my iTunes ripped albums as well.

I am trying to provide constructive feedback to highlight how MC is operating counter-intuitive to a potential new user.  It is important that a very complicated product behave intuitively.  S/W developer need to look at their product with "new eyes", and not assume all users are intimately familiar with the products features and quirks.