INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Rip Track Numbers  (Read 15030 times)

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Rip Track Numbers
« on: August 09, 2013, 03:28:33 pm »

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.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #1 on: August 09, 2013, 03:36:42 pm »

If you have [Track #] as a filename component under your File Locations > Audio > Filename rule, you should already get this.
Logged
The opinions I express represent my own folly.

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #2 on: August 09, 2013, 03:52:10 pm »

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.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #3 on: August 09, 2013, 04:03:40 pm »

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.
Logged
The opinions I express represent my own folly.

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #4 on: August 10, 2013, 09:12:42 am »

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.
Logged

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #5 on: August 10, 2013, 09:43:13 am »

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.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #6 on: August 10, 2013, 11:49:53 am »

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.
Logged
The opinions I express represent my own folly.

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #7 on: August 10, 2013, 11:50:53 am »

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.
Logged
The opinions I express represent my own folly.

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #8 on: August 10, 2013, 12:36:15 pm »

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!
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #9 on: August 10, 2013, 12:40:49 pm »

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.
Logged
The opinions I express represent my own folly.

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #10 on: August 10, 2013, 12:51:28 pm »

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)"
Logged

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #11 on: August 11, 2013, 08:01:28 am »

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?
Logged

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #12 on: August 11, 2013, 08:12:14 am »

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?
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #13 on: August 11, 2013, 12:33:13 pm »

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
Logged
The opinions I express represent my own folly.

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #14 on: August 11, 2013, 04:21:34 pm »

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.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72377
  • Where did I put my teeth?
Re: Rip Track Numbers
« Reply #15 on: August 11, 2013, 04:29:25 pm »

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.
Logged

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #16 on: August 12, 2013, 07:31:34 am »

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".
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #17 on: August 12, 2013, 12:20:15 pm »

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.
Logged
The opinions I express represent my own folly.

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #18 on: August 12, 2013, 12:24:48 pm »

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.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #19 on: August 12, 2013, 12:27:53 pm »

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.
Logged
The opinions I express represent my own folly.

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #20 on: August 12, 2013, 03:57:08 pm »

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 #.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Rip Track Numbers
« Reply #21 on: August 12, 2013, 04:08:06 pm »

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.
Logged
The opinions I express represent my own folly.

SilverLitz

  • Junior Woodchuck
  • **
  • Posts: 73
Re: Rip Track Numbers
« Reply #22 on: August 13, 2013, 08:16:45 am »

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.




Logged
Pages: [1]   Go Up