Print

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

[arin]

Hi!
I'm trying to import a huge .mpl playlist I made in MC Mac into MC Windows and getting nothing at all...
The hard drive where all the audio files are stored is the same but of course, as the different OS see it in different ways, I reckon the problem must be in that difference.
Is there an easy way to edit the playlist to make it pointing in the right direction for all the files?

Thanx

[MrC]

You must do two things:

   1. Change the Filename entry within each <Item> in the playlist so that it matches the path of your files on Windows
   2. Change the line-endings of the files to be Windows line endings.

I've made several postings one this in MC Mac 18 and 19. I think I also wrote a conversion script, but don't recall if I posted it, as there seemed to be no interest.  Maybe you can find the threads.

[arin]

Thank you!
I'll try to search deeper in the threads!

Only to make sure I did understand, by "Change the line-endings of the files to be Windows line endings", you mean the file suffix?

[MrC]

I found the script I wrote, but it needs a minor change to work with MPLs (it was written for M3U playlists).

I was afraid you were going to ask about line endings.  Windows, Mac OS and Unix / Linux all use different byte sequences to signify the end of a line in text files.  I can't recall now, but I believe the playlists must have the correct line endings for the platform to be imported by MC.  This may have changed.  In any case, I fix up the script in the morning and post it here for you.

[glynor]

Windows, Mac OS and Unix / Linux all use different byte sequences to signify the end of a line in text files.

* glynor pushes his glasses up his nose.

OSX is UNIX, and it uses unixy newlines (LF).  Old MacOS didn't (CR), but old MacOS is dead, Jim.

Pretty much every OSX application I've ever used deals properly with Windows-style (CR/LF) newlines as well.

[Hendrik]

I would hope the playlist importer would be able to deal with both - and if you can confirm this is an issue, let me know, and I'll fix it.

[MrC]

OSX is UNIX, and it uses unixy newlines (LF).  Old MacOS didn't (CR), but old MacOS is dead, Jim.

Pretty much every OSX application I've ever used deals properly with Windows-style (CR/LF) newlines as well.

Mr. Pedantic - your patience with my lax description is much appreciated.  :-)

RE: the OSX application handing of CR/LF, that won't be relevant to a playlist created on the Mac but being opened by a Windows app.

I would hope the playlist importer would be able to deal with both - and if you can confirm this is an issue, let me know, and I'll fix it.

I agree, it should.  In the past, it didn't, so it should be double checked.  In any event, absolute playlist path names have to change, so there's a file edit/conversion either way.

Now if you really want to be swift, MC could detect that the Filename's are for another platform, and offer the user a chance to do on-the-fly conversion, including replacement of a base path (/Volumes/... ==> M:\Music\...).  In otherwords, it could bring up a Rename, Move and Copy like dialog in Update mode, allowing the user to replace the base part of the path so the import would just work (MC would handle the / <==> \ conversion).

[glynor]

Mr. Pedantic - your patience with my lax description is much appreciated.  :-)

I don't even wear glasses. 

[MrC]

Edit: MC version 19.0.131 can directly import Mac iTunes's XML playlists - there's no longer a need to use this script for those playlists types, unless you also want to change path components as well (using -m transformations).

Here is a script to convert M3U's or MPLs bidirectionally between Mac and Windows.  It will also convert iTunes XML playlists so that MC can import them (currently Mac only, until I get a Windows version of an XML file to test).

The perl script is attached.  Download and unzip it.  To run it, it works like this:

   perl  convMCplaylist.pl -m 'old|new' path ...

You specify old and new; where old is the part of the file name in the playlist that you want replaced with the new.  Typically these will be common base paths, such as:

    /Users/mrc/Desktop  =>  M:\Testing\Music

Consider the file paths:

     Mac: /Users/mrc/music/artist/album/track.mp3
     Win: M:\Testing\Music\artist\album\track.mp3

The -m to use would be:

    -m '/Users/mrc/music\|M:\Testing\Music\'

You can use as many -m mapping transformations as you want; they are applied in the order you specify them.  They apply to all lines in the file, so be careful.

If you don't need any additional mappings beyond those done automatically for specific playlists types (i.e. for iTunes' XML conversion), use:

  -m -

The path argument is one or more playlists and/or folders containing playlists (m3u, m3u8, mpl).

The script handles swapping path separator characters for you.

The playlist files will be changed in place, and the originals will be saved as <playlistname>.orig.  If you don't want the backups, remove the ".orig" at the top of the script (leaving "#!/usr/bin/perl -i").  Still, you might want to copy your playlist folder just in case something goes wrong for easy recovery.

Once converted, you should be able to bring them over to the other platform and use File > Import Playlist to import them.

Examples:

    perl convMCplaylist.pl -m '/Users/mrc/Desktop/|M:\Testing\' ~/Desktop/test
    perl convMCplaylist.pl -m - ~/Desktop/iTunesPlaylist.xml

[arin]

Thanx a lot MrC, your advice, guidance and work are always much appreciated.
I'll have a try with your script tomorrow... Hope that I'll manage to get it working.

I was really amused by glynor remarks...and I do wear glasses!

[MrC]

I've posted version 1.2 above.  It can handle iTunes' XML files on a Mac, to be imported into MC.  See also:

   http://yabb.jriver.com/interact/index.php?topic=87171.msg610557#msg610557

ignoring the steps 2 - 5, which are the parts about opening and editing with TextWrangler, since the script does all that for you.

I'll add the code to do iTunes XML conversions on the PC once someone sends me an iTunes XML created by iTunes on a PC (I don't run the monster on Windows).

[glynor]

I'll add the code to do iTunes XML conversions on the PC once someone sends me an iTunes XML created by iTunes on a PC (I don't run the monster on Windows).

What do you need?

I have some Windows iTunes installs.  I don't really use them much, but I could make it spit stuff out.  You just want the whole Library XML file, or do you need me to generate one somehow?

[MrC]

Probably just one playlist with one entry is fine.  I'd like to see how paths are handled there, and then I can add the conversions.

Thanks.

[MrC]

Ah, no need glynor.  I'll just snapshot a Windows VM and install to test it out.

[MrC]

There's no need to do any conversion from a Windows iTunes' XML file.  MC will import these directly w/out change.

[arin]

Ooops...
I forgot to report that I tried the script some time ago and it worked...well, almost: it only left out some 300 files out of 75000!:)
I only tried it with a m3u playlist from the mac to windows. I still have to try out other formats though.
The funny thing is that I tried to reimport the original playlist (that is without transforming it with the script) in iTunes on the mac and it also left out more or less 200 files!
Maybe iTunes has some really big problems exporting playlists...

[MrC]

I doubt the script left anything out - it just converts lines as needed, and passes everything else untouched.  So the likely culprit would have been MC not importing the files for one of several possible reasons (it thought the file was bad, or maybe the character set not being correct for M3U, or ?).

It would be good to identify one such file, and see how it looked in the converted M3U file and what MC did with it.

[glynor]

There's no need to do any conversion from a Windows iTunes' XML file.  MC will import these directly w/out change.

I thought so.

[MrC]

MC Mac 19.0.131 can now directly import OS X iTunes' XML files.

[arin]

I doubt the script left anything out - it just converts lines as needed, and passes everything else untouched.  So the likely culprit would have been MC not importing the files for one of several possible reasons (it thought the file was bad, or maybe the character set not being correct for M3U, or ?).

It would be good to identify one such file, and see how it looked in the converted M3U file and what MC did with it.

I'm going to test some other playlist formats just to be sure. Then I'll try to spot some of the missing files and let you know.

[arin]

So, after a long time I had time to do some tests again.
I exported an mpl playlist from MC Mac and it seems I was able to import it completely in MC Win...but now the problem is I got many duplicates files.
And after some analysis of the duplicates I realized that every time MC has to deal with some accented or special characters (for example à, è, ü, ö) it fails to look for the existing file that is already in the library and seems to reimport it.
And in fact I end up with many duplicates that look exactly the same but if I try to locate on disk one of the existing ones, it points normally to the file on my external drive, if I ask to locate one of the newly imported ones, it open the user files folder on the internal drive without highlighting any file, of course…

Is there any way to batch link these fake entries to the files on my external drive?
Or maybe MrC could do some magic with his script to avoid this problem? 

[MrC]

It might be that this is an encoding issue.  Can you paste one Filename line from the Mac-created MPL?

I'm wondering if the characters you mention are (HTML-encoded) UTF-8 in the Mac-created MPL, but those characters properly map to Latin1 on Windows, which is the default codepage used for Windows.

For example, the letter è is two bytes in UTF-8 encoded as 0xC3 0xA8, but is one byte in Windows Latin1, encoded as E8.

[arin]

Hi MrC,
thank you for your prompt reply!

I noticed that if the name of an album, artist or album artist has an accented or special character, the whole album is duplicated with fake files.
Anyway, here are some Filename examples extracted from the Mac MPL:

<Field Name="Filename">/Volumes/Server10/iTunes Media/Music/Antonio Carlos Jobim/Antonio Brasileiro/14 Chora Coração.m4a</Field>

<Field Name="Filename">/Volumes/Server10/iTunes Media/Music/Alban Berg/Alban Berg Collection/5-11 Lulu - Act I - Scene 3 - _Über die ließe sich freilich eine interessante Oper schreiben_.m4a</Field>
(Here the underscore character are actually the character ")

<Field Name="Filename">/Volumes/Server10/iTunes Media/Music/99 posse/La Vida Que Vendrà/10 A Una Donna.m4a</Field>
(Here I think the problem is actually the album name)

<Field Name="Filename">/Volumes/Server10/iTunes Media/Music/Anaïs Mitchell/Young Man In America/05 Venus.m4a</Field>
(Here I think the problem is actually the album artist name)


Shouldn't these be enough, I will send you more of them…

[MrC]

Sorry, the pasting won't help, as transformations happen.  I checked my own values.  The MPLs on the Mac us a different form of Unicode than Windows.  And doing a Rename on the Mac file with this value causes MC Mac to not recognize it was renaming the file to the same name (and then it of course errors out).  The Mac side is not setting the normative form to convert the standard+combining characters into the simpler UTF-8 sequences.

Mac:
Déjà  44 65 cc 81  6a cc 80     D  e + combining acute accent (0xcc 0x81)  + j + a + combining grace accent (0xcc 0x80)

Windows:
Déjà  44 c3 a9 6a c3 a0          D + é (0xc3 0xa9) +  j + à (0xc3 0xa0)

While I could write a conversion script to normalize the Mac MPLs, MC Mac needs to get this right because of the Rename problems, minimally.

[arin]

I see...
So I think one solution would be to delete all the fake entries and then looking for incomplete album inside the playlist and ask MC to integrate them.
Do you think this could be done?

For the albums missing completely from the playlist (due to Album or Album Artist names) I can't think of any other solution but to go and pick them up one by one...

Thank you for your attention!

[MrC]

You can certainly manually go through and find the discrepancies.

Let's see what JRiver has to say.  It might take a couple of days.