Print

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

[couchjr]

Wise ones,

We are trying to transfer tag values written into multichannel DSF files in MC 19 Windows to stereo DSF files of the same albums created on the Mac, where I have MC 19 for the Mac. We have successfully done this for individual albums by simply importing the m-c files on the Mac side, replacing them with stereo files in the same folder, and updating tags from library and then updating library from tags. This way the file path that MC sees doesn't change.

This would be a very slow and cumbersome method for large numbers of albums, not least because all the multichannel files would have to be copied onto the Mac (at ~6-7 gigs each).

After perusing Mr. C's heroic work on these threads:

http://yabb.jriver.com/interact/index.php?topic=82720.0

http://yabb.jriver.com/interact/index.php?topic=78971.0

we have been thinking that creating an MPL file of, say 100 albums' worth of tags at a time from the multichannel files, sending that to the Mac side, and importing that into the MC Mac library and updating the stereo files from that MPL file would be infinitely faster and easier. But given our current limited understanding of MC, we have one major puzzle to solve:

The paths that are shown in the "Filename" field in the MPL file are presumably in Windows notation and syntax (I haven't seen one yet) while the computer, the edition of MC and its library, and the drive where the stereo files will be stored are all Mac based, so (based on a test MPL I created on the Mac side) they use unix file system notation and syntax. So even if the source multichannel media files and the receiving stereo media files are located at the same level of an attached drive/volume on each system, we don't yet know whether MC Mac can find the receiving files to do an "Update file tags from library" operation without the update failing.

If it's just reading characters in the MPL field, how will it connect "/volumes/volumeName/directory" to "Z:/directory" or whatever Windows writes into the MPL field? Is there something in auto-import, or "Rename, Move, & Copy Files" that can help here for an entire batch?  The actual filename (the part after the final slash) should already be an exact match, so that's not an issue. Just the path.

I also noticed that when exporting an MPL, there's an option to store the path relative to the location to which the MPL is exported. So would it work to always export the MPL to the same directory in which the media file folders are located? That shortens the path in the MPL field to just \albumName\filename (on the Mac side at least).

I'd prefer, if possible, not to have to edit the paths in the MPL file using search-and-replace to match the Mac syntax before importing. It would be tedious, and I'd worry about mistakes or typos screwing up something else in the filename.

If a script is needed, I see that OS X can run perl at the Terminal shell command line, though I have no experience with perl.

If MC is smart enough to translate the path it sees in the MPL field to find the files stored at the same level in the Mac file system and update the tags without further intervention, I'll be deliriously happy. I really hope the only hurdle here is my ignorance.

But if, as I suspect, there's more to it, I'd be very grateful for guidance. Has anybody done this kind of cross-platform update of, say, mp3 to FLAC versions of the same albums using MPL files?

Thanks in advance for all advice and experience. If anything's not clear I can supply examples, rephrasing, and/or libations to deities of your choice.

 

[jlyness]

I have a broadly similar need, for a different situation. I have a lot of SACD ISOs in my MC library; the tags are stored in the library file, since they cannot be written to the ISO files. If I were extract these ISOs to DSF files, the tags could be written to the DSF files. But: a) to do that one album at a time, without having to manually recreate all my tags, I would need to use the "copy-paste tags" feature of MC, except it appears this feature is not yet enabled on the mac version of MC; and b) is there a way to do that for all at once, rather than one album at a time?

[MrC]

@couchjr...

If you export your file's metadata as an MPL playlist on Windows, then you can import it on the Mac provided the following:

   1. you convert the Windows paths to Mac OS X paths
   2. the files exist at the corrected path specified in (1) above.

The path conversion might be as simple as converting backslash to forward slash, and replacing the drive letter with the appropriate root component, or it may be more complicated if the folder mappings are not otherwise identical on both OS'.   If it is simple, a quick substitution in the Filename field for each MPL can do the work in one shot.

@jlyness...

The same principle should apply here, but you'd need a mapping from the ISO file path (which you can see in the MPL) to the individual DSF files.  If you can show the basic algorithmic mapping from ISO to DSF, it shouldn't be too hard to create an importable MPL.

[couchjr]

Thanks, MrC--If I understand you correctly, you're advising that for each batch of albums in a single MPL file (~100), I would do a global search-and-replace edit of the path portion of the filename field to make the Windows path notation match the OS X unix notation. Do I have that right?

That means I'll have to do this for at least thirty batches, and more as the DSD collection grows. It also has implications for collection/storage management. If we need to use MPL files to transfer corrections or add metadata fields later, we'd have to keep all the albums in the same directory on both systems, or figure out a way to sort and group all the albums in a given directory before making an MPL so the MPL will find all the correct files.

I was hoping there was a more automated way, but this is still far better than swapping individual album tags.

It may take some experimenting to get the Windows->Mac OS path translation right. To begin with, at least, I think we can store all the media files at the first user-definable directory level on attached storage on both systems, so that should help some.

Do you think using the "relative path" idea I mentioned earlier might simplify the translation?

Many thanks for your insights!

[MrC]

First let me preface that I don't have any DSDs/DSFs and I don't know if MC handles writing tags to the files or via sidecar.  So any "advice" i'm suggesting is along the lines of how something can be accomplished as opposed to perhaps some other, better way.  IF MC is not writing tags or sidecars for your file types, then MPL is one way to import file properties into another MC library.

Having said that, yes, a global search/replace of the Filename fields inside the MPL is what you'd do.

I'm not clear on why you are doing batches, as opposed to the entire library all at once.  But I'm sure you have your reasons.

Relative path appear to be supported.  I'm embarrassed to say I've never tested them with an MPL.  I know there was an issue with relative paths and other playlists types in MC Mac and I don't recall if it was resolved.

Ask if you need help with a quick script / command line to perform the translation.  In another thread, I created an Automator scriptlet that converted paths in a playlist from Windows to Mac - this would be similar if that was easiest for you.  Include some sample Before and After paths so I can see the translation pattern needed.

[couchjr]

MrC, thanks again for your generosity and patience. Your advice in other threads has already helped us a great deal, and taken us as far as we've already come, so we're very grateful.

It seems that MC does indeed write tags into the DSF files via the "Update file tags from Library" command, so that's not a problem. Given the goal below, does that mean there's an easier way? I'm very new to MC and hi-res computer audio generally, so please don't hesitate to tell me if I'm missing something obvious. It may also be obvious that I'm not a programmer.

Our goal is to convey the tags from multichannel DSFs, being tagged by one person in Windows, to the stereo DSFs of the same titles, from the same ISOs, resident on a Mac (and extracted at a different time). The multichannel files are still being tagged (including some custom fields) so if we did the entire library at once, we'd have to wait until they were all tagged, which would take a long time--weeks or months. And any method that involves copying DSF files from one computer/drive to another involves a lot of wait time. Those are our reasons for batching. We thought sending an MPL file to the Mac to transport the tags for the stereo files would be far faster and easier than sending copies of all the multichannel files and swapping them out as in the "re-ripping" method described on the wiki. If there's an efficient way to do larger batches, or even the whole library, I'd love to know it. If it's fast enough, it might make sense for us to wait and do them at the end--though that would probably mean I couldn't find or play any of the stereo DSFs in the mean time .

I should be able to test doing a search/replace on the path portion of the filename field of a simple MPL using each of the absolute and relative path options sometime this week. If I can make it work, I should be able to let you know what the most efficient viable "before" and "after" paths are (part of this evaluation will involve making sure we can dependably repeat the export location of the MPL in our workflow). If the relative-path method works it might be as little as changing a single character, if we export the MPL to the same directory where all the album folders live.

I've never used Automator, but if you were able to write a scriptlet it sounds like it would save time and more importantly reduce the risk of errors if we have to do many batches. The collection of (nearly all) classical SACDs we're backing up runs to more than 3000 disks and will grow, so volume and time are concerns.

Thanks again.

[MrC]

You're welcome.  Your approach (of importing the tag values) seems reasonable.  Once you try a few and gain experience, you'll find it is pretty easy.

[couchjr]

Began testing tonight. New problem: could not get MC Mac to import an MPL file created by MC 19 Windows. During the import step, when I browsed to navigate to the albums.mpl file, it was greyed out and could not be highlighted to finish the import (other folders visible in the browse window were not greyed out). I tried using three different, freshly created and exported MPLs--same result.

The file was created in and exported from MC 19 Windows to a directory at the topmost user-definable level of the file system, right after the C: drive designation. (The media folder referred to by the playlist was in the same directory). The albums.mpl file was then copied onto a thumb drive, inserted into the MacBook Pro, and copied from there into a directory at the same level of the Mac file system (where the media folder to be updated was also at the same level). Then I tried the import, with results as above.

I was able to open any of the MPL files on the Mac to read using BBEdit, a competent text editor on the Mac. Each file looked like a well-formed XML file to me, and BBEdit color-coded tags, values, etc. as expected. I did notice that the MPL file showed up in Finder with a dark-terminal-screen icon with "exec" in lime green and a"Kind" value of "Unix executable file." If I saved the file after opening it in BBEdit, it changed to a generic "document" icon and a "Kind" value of "Simple text document." (That version wouldn't import either--I tried.)

I tried creating, exporting, and importing an MPL of the same album from the Mac version of MC, and it imported fine. The albums.mpl file icon was a generic document icon and the "Kind" just said "Document." If I opened and saved this in BBEdit, it also changed to "Simple text document."

I presume there's nothing in the actual content of the file itself that would cause this problem, but rather something in the file format, extension, or metadata pertaining to MC Windows that MC Mac can't recognize. Can someone help? Can you duplicate this in JRiver land? Is it a bug or have I missed something?

It's particularly frustrating because reading (in BBEdit) the MPL files exported from both Mac and Windows versions with the relative paths option checked, the path in the "Filename" field was precisely identical in both. So if I can get MC Mac to import the Windows MPL file, I can probably use it to update tags with no translation of the path notation required at all! (Of course, when I exported without the relative paths option checked, the differences in notation and drive designation showed up, proving that the exported file was in fact coming from the other machine, and not an accidental duplicate of the one created on the Mac.)

Any fixes or further troubleshooting instructions welcome. Thanks!

[couchjr]

I just noticed MrC's comment on another thread:
   
    Re: Playlist transfer
    « Reply #9 on: November 20, 2013, 01:08:05 pm »
   Reply with quoteQuote
    This seems to be an MC Mac problem.  Neither MC18 nor MC18 are importing Unix/Mac style paths in an M3U playlist.

I noticed that the Windows MPL exported with relative paths checked seemed to use a style identical to Unix style paths, e.g.:   .\filename\01 etc.

Related?

Although the MPL exported without relative paths checked seemed to use normal Windows style, and that couldn't be highlighted for import in the browse window either.

[MrC]

I do MPL imports on the Mac routinely, and just tested in again.

Be sure the file suffix is really .mpl (do a Get Info).

The Relative paths option does not produce the correct paths, as you've noticed.  So these imports fail.

[couchjr]

I get the same greyed out behavior whether the paths are relative or not. I've attached a screen shot of the "Get info" screen of an MPL created on MC 19 copied to my drive. File extension shows as .mpl.

When you say the relative imports fail, do you mean you can select the file and hit the "Finish" button and then you get an error message that the import fails? Or are you not able to select the file? I'd expect the former behavior. Why would a pathname in a tag value prevent the browse widget from recognizing the file as valid? (I did have the MPL file type checked in the import dialog, and have attached a screen shot of that. I've also attached a screen shot of the browse window in the Import dialog, showing the greyed out files.)

I just checked the thumb drive I used to convey the MPL file from the Windows machine to the Mac, and discovered that it's formatted as MS-DOS Fat16. Is it possible that OS X misreading from this format is could cause the issue? I'll ask my colleague to email me a copy of the MPL file and see if that changes the behavior.

The relative path looks absolutely correct for the Mac; when I created an MPL with relative path on the Mac version it found the file without trouble, and the path is the same as what the Windows version created. So even if it wasn't styled correctly to work on a Windows machine, it should work on the Mac if the MPL file and the media folder are in the same relative position (both in the same directory), no?

If that was just dumb luck, when do we expect relative paths to be fixed in MC? It will save me a lot of time.

Thanks!

[MrC]

Your files show as Kind: Unix Executable File, and not MPL File, and there is no Open With application associated.

By FAIL, I meant the MPL file itself is selected and imported into MC, but the referenced media files are not imported (or have properties updated).  When you import a playlist, both the playlist file itself, and the referenced media files are imported (when possible).

Don't use Tools > Import.  Use File > Import Playlist.

[couchjr]

Yes, I said in my earlier msg that even though the file suffix is .mpl in all views, the Mac thinks the file is a Unix executable. I'm hoping re-acquiring the MPL without going through a storage format other than NTFS or HFS+ will correct that--will report back.

Thanks for the instruction to use File -> Import Playlist. Hadn't discovered that method. If Tools -> Import doesn't work reliably for MPLs, perhaps the option to import MPLs should be (at least for now) removed from that tool?

Thanks also for the description of failure mode. This encourages me somewhat; we're troubleshooting two separate problems.

Question: if importing the MPL also imports the referenced media, does it automatically update the tags in the referenced media files? I was assuming I'd need to import the MPL, then do "Update tags from Library" before importing the media files. If importing the MPL updates the tags in the referenced files automatically, that will be great, but something to know for workflow. Recall that we're using the MPLs as a way to batch-transfer tags from multichannel dsf to stereo dsf versions of the same ISO's tracks. Clarification of sequence of operations here would be welcome.

Thanks again! More anon.

[MrC]

An MPL import will both import the files when possible, and update the file's properties as per the Field values in each Item in the MPL.  An MPL is more than a simple playlist - it is a per-file properties list.  I do this routinely, as do other folks (in fact, my AMG script creates an MPL for importing metadata from AMG, so MPL importing has been routinely tested).

I assume the reason Tools > Import does not update properties the same way that File > Import Playlist does is that they are two distinct operations.  Tools > Import is about importing just files, including MPL playlist files (which will be imported, and stored under Playlists > Imported Playlists).  File > Import Playlist is a manual operation which allows you to force update properties via MPL.  Since properties cannot be update if the files are not imported, the media file import is a requirement for the operation to be useful.  Simple playlists types just import the referenced files, as they have no associated properties.

The MPL file I showed in the above screenshot was generated on Windows/NTFS and then coped to the Mac's HFS file system.  I don't believe the Browse dialog examines the file's contents - only the file type - so line ending differences would be irrelevant.  Maybe setting the file association will help.

[couchjr]

Thanks, Mr.C. That did it!

Using File -> Import Playlist, all the MPL files (the ones with unix line endings and "unix executable" file type, the ones with just "document" file type, and the edited files saved by the text editor as "simple text" file type) were selectable in the Browse dialog. All would import. As you predicted, the ones with relative paths failed to import any media files. The one I edited to match my MacOS path style worked like a charm. Just to be sure I've understood your last post, I think you said the MPL import operation writes the new tags into the media files, not just the MC Library database. So I don't have to run "Update file tags from Library" now. That's terrific--please confirm.

So until MC gets the relative paths piece of this import sequence working, I'll take you up on your generous offer of doing an Automator script to translate the paths (I'm hoping that this can apply to all files in all albums imported by a given MPL, which may be 50-100 albums). I'll provide the before and after strings as soon as we have agreed on a naming convention and location relative to root for the directory these will live in.

I note that MC MPL seems to create the "Filename" field by combing the album name and the actual filename (which as generated by SACD_Extract begins with a track number), separated by a back or forward slash. So it looks like the script will need to do two operations: delete "Z:" (or equivalent) and change all slashes to forward slashes. Once we agree on a standard naming convention, the container directory holding all the album folders should retain the same name. Will advise when ready.

Thanks again!

[MrC]

Good to hear.

I think you said the MPL import operation writes the new tags into the media files, not just the MC Library database. So I don't have to run "Update file tags from Library" now. That's terrific--please confirm.

The import updates the Library (MC's database).  Tags are opportunistically written out to files as per your auto-import settings for those files, and the Update Tags When File Info Changes setting.  Or you can manually write them out via Update Tags (from library).

I note that MC MPL seems to create the "Filename" field by combing the album name and the actual filename...

No, the Filename field is entirely a function of the file's path, as discovered when the file was imported into the Library.

[couchjr]

OK, thanks. For safety, then, I think when I import an MPL I'll select all the albums and run the "Update tags from Library" command just to be sure.

Of course you're right about the MPL fillename path. Album name is the folder name as created by SACD-Extract. Duh. My apologies for transient idiocy.

Your help is invaluable. Much obliged.

 

[jlyness]

I have a f/u question to my query above about transferring metadata in my MC library about an SACD ISO to the corresponding DSF files. What about transferring the metadata about an SACD ISO from one MC library to another MC library on another computer, with the 'same' SACD ISOs but stored on a different drive? Is that any different, or would I still need to manually change the path for each ISO in the MPL file?

[MrC]

jlyness, that's correct.  The Filename component is the key component, so for the second library, update Filename in the MPL to match the files on the second system.

[jlyness]

Thanks, but sounds like I'd have to do that individually for every single file I'm updating? It would be quicker to just re-enter the meta-data (especially if/when you enable copy/paste metadata for the mac version of MC).

[MrC]

No, you can do all of them at once.   If you can export an MPL playlist for your set of files A, and the only thing that is different with your set of files B is the initial path component, such as:

   A's Filename: /path/to/files A/...
   B's Filename: /path/to/files B/...

you can change "/path/to/files A/" to "/path/to/files B/" in an editor, then you can just import the MPL playlist on B, and all the tags that were in A will go to the corresponding files in B.  This will even work if the file suffixes differ, and you change them (e.g. foo.mp3 ==> foo.flac).

Make sense?

[jlyness]

It does, will try it, thank you again!

[couchjr]

Followup: Now happily doing transfers via an mpl. Mr_C, I've found that swapping the drive name and slash direction for paths is easy enough to do in an editor that I won't need to accept you generous offer of an Automator script. However, there's now one last hurdle to doing these efficiently, unrelated to JRiver but relevant to this process, so I'm posting the question here as well as in a new thread and on Computer Audiophile:

Out of caution, I'm extracting a bunch of iso files using sacd_extract to dff and then converting the dff files to dsf using Audiogate for tagging via an mpl in JRiver. Sound is great. But most of these are classical, and Audiogate strips all commas from the track names (surprising how many there are--eg., "Quartet in A major, K. 123, 1. Allegro"). This means I have to manually replace the commas for every !@#$ track name, which takes forever. I presume the comma stripping means that Audiogate is using commas as a delimiter. My question is, does anyone know how (setting, rule script, etc.) one might change the character Audiogate uses as a delimiter to something rare like £ so that it won't strip commas from track names? The free (mandatory tweet) version of Audiogate offers no user support . . . . and I couldn't find anything useful in the online manual.

Thanks for any assistance!

[MrC]

Thanks for the follow-up.

Edit: my original reply here moved to your other thread.

[couchjr]

Thanks, Mr_C.

I'm not sure we're on the same page. I want to *keep* the commas in the filenames. Not only do they read better, but the large mpls with all the album tags (made by a colleague, and via which I'm importing all my converted dsf files and extensive tagging) have all the commas (the mpls were created from multichannel extracts of the same ISO files which did not need to go through the DFF-DSF conversion).

My extracted stereo DFF files have the commas. When Audiogate converts the stereo DFF files to DSF files, it strips the commas from the filenames. So the output from Audiogate is a DSF file with no commas. I can't import that file into MC via the mpl because the mpl won't see it. The commas *within* the filenames are not used as delimiters, but as natural language commas. There's no consistency across albums as to how the commas are used within filenames and many albums don't have them.

What I think is happening is that Audiogate is using commas as internal delimiters between files, to keep them separate, since it will convert large batches at a time. Therefore, it strips the commas *within* each filename so that it won't break files into random pieces.

WAIT--maybe I see a possible variant on what you're suggesting. Check me and see if these steps make sense:

1. Delete all existing files from MC Library.
2. Directly import (not via mpl) 100 or so DFF-file albums with commas in filenames.
3. Select all albums
4. Use Rename, Move & Copy as follows:
    A. Select "Rename" as base path and naming template
    B. Check "Find & Replace"
    C. In "Find What:" insert a comma
    D. In "Replace With:" insert a £
    E. Click "OK"
This should result in all filenames being changed in the MC library to replace , with £
5. Select all albums and choose "Update tags from Library"
This should result in the DFF filenames on my attached drive being changed as above (correct?)
6. Run the no-comma DFF files through Audiogate to convert them to no-comma DSF files
7. Delete everything from the MC library
9. Import the no-comma versions of the DSF files and select all albums
10. Use the Rename, Move & Copy tool to reverse the steps in #4 above to restore commas
11. Select all albums and choose "Update tags from Library" to transfer restored-comma filenames to files on disc
12. Delete all albums from MC library
13. Import comma-restored DSF files via the mpl and update tags in both directions as usual

If this works, and is safe, it would probably take far less time than manually replacing commas, but it would be much faster still if I could just change the rule within Audiogate once and be done with it. Pointers in that direction still welcome.

Anyway, thanks for this idea, and please let me know if the above sequence would do what I think, or if it needs tweaking.
 

[MrC]

That's the idea.

I'm not sure about your reason for Step 5:

   5. Select all albums and choose "Update tags from Library"
   This should result in the DFF filenames on my attached drive being changed as above (correct?)

but test it to see.

You could strip the commas from the MPL within the Filename field's value instead.

[couchjr]

Does the Rename, Move & Copy utility operate directly on the files on disc, or only in the Library?

If the former, you're right, I don't need steps 5 or 11.

If the latter, the reason is to change the files on disc so I can manipulate them outside MC (in Audiogate).

I will certainly test with one album, since the only efficient way to do this will be to operate on the original files, because to make a backup copy of 100 DFF albums will take at least a couple of hours . . .

Let me know, and thanks again.

[MrC]

It can do either, or both.  Filename is a field - it is intented to always reflect the full path to the file on disk (otherwise, MC can't find the file).  If you use the RM&C tool, you can affect the file's location on disk.  And the Filename field is always updated in a Rename or a Move.

Sometimes you move files outside of MC, and then use the tool in the Update.... mode to correct the Filename field only.

[jlyness]

Just following up on the advice above, find and replace in the MPL file did the trick for me. Smooth sailing with ~20,000 tracks. File art didn't transfer, obviously, but internet search fixed almost all of the missing cover art, too. Thanks again for the advice and help.