Print

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

[aaronsama]

I've got a lot of classical music, but I run into issues when I have accented characters and I try to import my files onto my iPhone for mobile listening. I'd like to find a way to do rename files with special characters to those without.

Currently the Clean() function doesn't handle this use case, and if I were to try to use the Replace() function, I'd have to run it once for every single possible accented character, i.e. Replace(Replace(Replace([Filename],á,a),ř,r)...) ad infinitum.

Is there a way to do this within JRiver? If not, is there a way to do this over the command line so that I can code up a solution to do it for me?

Future feature request ... ReplaceAny(Field, List, Replacement) function which takes anything in List and replaces it with Replacement. Bonus points if it can be built like IfElse function, e.g. ReplaceAny(Field, List1, Replacement1, List2, Replacement2...)

[terrym@tassie]

Have a look at this forum post https://yabb.jriver.com/interact/index.php/topic,99583.msg836593.html#msg836593
it describes removing diacritics using MC Replace expression.

[aaronsama]

Thanks for sharing.

I get the point of having a field with all the special characters removed that you can easily make filenames from, but if I'm going to do that, I still have to use the Replace(...Replace(Replace(...,á,a),ř,r)...) ad infinitum solution. Which is what I ended up doing, but I just put the Replace chain into my "Rename, Move & Copy" expressions. Ended up with just shy of 100 Replace()s in the chain.

It's ugly code, but it does the job. I really wanted to find something more elegant, but alas.

[blgentry]

I still have to use the Replace(...Replace(Replace(...,á,a),ř,r)...) ad infinitum solution. Which is what I ended up doing, but I just put the Replace chain into my "Rename, Move & Copy" expressions. Ended up with just shy of 100 Replace()s in the chain.

You could make a new field to hold the converted [Name] field, which you could then use in Rename expressions.  Something like [Name ASCII].  Did you know fields in MC can be expressions?  So you can put your giant replace(replace( expression into a field and just leave it there.  It will be automatically calculated for every song/file you have. 

I just resisted that really old thread with my original weird ideas in it and found my original program that I was going to use.  I don't really like my external program very much.  Honestly I'd kinda like to use a giant replace(replace( expression on a few albums in my library.

So I cut and pasted the big expression from the linked thread.  It "only" has 37 replacements and isn't very comprehensive.  It didn't work very well on the first album I tried it on.

Would you paste in your 100 wide replace expression here?  If not, I can probably find some reference table and then turn that into an expression with some editor magic.

How did you put together your huge list of replacements?

Brian.

[blgentry]

Ok, I'm a little excited so I wanted to share.  I looked up a big table of diacritic to ascii conversions.  I believe there are 189 of them.  Then I constructed a giant replace(replace expression using them.

I made some new fields:  [Name ASCII], [Album ASCII], [Artist ASCII], [Album Artist (auto) ASCII] .  I actually shortened that last field name, but that's not important.

Using these new fields, I can now do Renames that convert all the diacritic characters to standard ASCII.  This is helpful as I use these files on several different kinds of file systems and some of them don't like those non-ASCII characters at all.

Here's one of the expressions in case anyone wants to use or modify it.

Code: [Select]

replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace([Name],À,a),Á,a),Â,a),Ã,a),Ä,a),Å,a),Æ,a),Ç,c),È,e),É,e),Ê,e),Ë,e),Ì,i),Í,i),Î,i),Ï,i),Ð,e),Ñ,n),Ò,o),Ó,o),Ô,o),Õ,o),Ö,o),Ø,o),Ù,u),Ú,u),Û,u),Ü,u),Ý,y),Þ,p),ß,s),à,a),á,a),â,a),ã,a),ä,a),å,a),æ,a),ç,c),è,e),é,e),ê,e),ë,e),ì,i),í,i),î,i),ï,i),ð,e),ñ,n),ò,o),ó,o),ô,o),õ,o),ö,o),ø,o),ù,u),ú,u),û,u),ü,u),ý,y),þ,p),ÿ,y),Ā,a),ā,a),Ă,a),ă,a),Ą,a),ą,a),Ć,c),ć,c),Ĉ,c),ĉ,c),Ċ,c),ċ,c),Č,c),č,c),Ď,d),ď,d),Đ,d),đ,d),Ē,e),ē,e),Ĕ,e),ĕ,e),Ė,e),ė,e),Ę,e),ę,e),Ě,e),ě,e),Ĝ,g),ĝ,g),Ğ,g),ğ,g),Ġ,g),ġ,g),Ģ,g),ģ,g),Ĥ,h),ĥ,h),Ħ,h),ħ,h),Ĩ,i),ĩ,i),Ī,i),ī,i),Ĭ,i),ĭ,i),Į,i),į,i),İ,i),ı,i),IJ,i),ij,i),Ĵ,j),ĵ,j),Ķ,k),ķ,k),ĸ,k),Ĺ,l),ĺ,l),Ļ,l),ļ,l),Ľ,l),ľ,l),Ŀ,l),ŀ,l),Ł,l),ł,l),Ń,n),ń,n),Ņ,n),ņ,n),Ň,n),ň,n),ʼn,n),Ŋ,n),ŋ,n),Ō,o),ō,o),Ŏ,o),ŏ,o),Ő,o),ő,o),Œ,o),œ,o),Ŕ,r),ŕ,r),Ŗ,r),ŗ,r),Ř,r),ř,r),Ś,s),ś,s),Ŝ,s),ŝ,s),Ş,s),ş,s),Š,s),š,s),Ţ,t),ţ,t),Ť,t),ť,t),Ŧ,t),ŧ,t),Ũ,u),ũ,u),Ū,u),ū,u),Ŭ,u),ŭ,u),Ů,u),ů,u),Ű,u),ű,u),Ų,u),ų,u),Ŵ,w),ŵ,w),Ŷ,y),ŷ,y),Ÿ,y),Ź,z),ź,z),Ż,z),ż,z),Ž,z),ž,z),ſ,s)
Thanks to @aaronsama for inspiring me to do more. 

Brian.

[Matt]

Would it make sense to pull that into a new function?

[leezer3]

Feels like it should be another mode for the Clean() expression function.

[Matt]

I'll hook this up today.  Thanks to blgentry for his help.

[afora]

Complex string replacements is a task best suited for the operating system not JRiver. If you are running Linux, it's just a one line command in the terminal:

Code: [Select]

iconv -f utf8 -t ascii//TRANSLIT yourfilename
There's plenty of resources on the internet e.g.:
https://stackoverflow.com/questions/10207354/how-to-remove-all-of-the-diacritics-from-a-file

If you are on Windows google for equivalent resources.

[blgentry]

Complex string replacements is a task best suited for the operating system not JRiver. If you are running Linux, it's just a one line command in the terminal:

Code: [Select]

iconv -f utf8 -t ascii//TRANSLIT yourfilename

The issue with this approach is that MC will not know about your changes.  Thus MC will no longer know that the file exists.  The record in MC will be orphaned and will not play.   You can let MC delete these orphaned records and you can also let MC reimport these files that you rename.  Then you will have all of your files again. 

But this is a poor approach for several reasons:
1. MC will lose all metadata about the file that is not stored inside the file.  Any custom fields, etc that you have defined that are not also written inside the metadata area of the file will be lost.
2.  Similarly, since these files will be re-imported, you will lose the import date for the files/albums.  For me this is important.  For others it might not be important.
3.  It just feels wrong to pull the rug out from under the application and hope that it cleans up correctly after you do so.  It's a much more mature and measured approach to let MC do the work of renaming the file and thus keeping track of everything.

All that being said, thanks for letting us know about iconv.  I've been a Unix/Linux/AIX/Solaris/etc administrator for about 30 years now.  I've never used iconv! 

Thanks,
Brian.

[afora]

But this is a poor approach for several reasons:
1. MC will lose all metadata about the file that is not stored inside the file.  Any custom fields, etc that you have defined that are not also written inside the metadata area of the file will be lost.
2.  Similarly, since these files will be re-imported, you will lose the import date for the files/albums.  For me this is important.  For others it might not be important.
3.  It just feels wrong to pull the rug out from under the application and hope that it cleans up correctly after you do so.  It's a much more mature and measured approach to let MC do the work of renaming the file and thus keeping track of everything.

No worries, Brian. And I grant it that the import-date/number-of-plays/etc could be valuable for some.

However, just curious from the grander level viewpoint:

- Are there any situations when you do not want to save metadata in the actual file (apart may be when file format does not support it - but then why keep that format)?
- If you store some metadata in the application database only, you are a hostage to a non-portable data structure - God forbids JRiver disappears in the current incarnation, how are you planning to migrate without losing meticulously organised metadata?
- If Import Date is that important why not create a custom field for it and never think about it again?

Thanks for your inputs, finding them quite valuable.
Cheers

[blgentry]

The answers to all of your questions come down to effort.

I know how to create custom fields.  I know how to make them write to my files.  But there is extra effort involved in verifying this.  MC does not always configure fields to be written to the file itself.  There are two different settings for this:  one global and one PER FIELD.  I would need to verify that this works and hope that I never change any of these settings.  It's doable, but it's "work".

Generally speaking I think MC can write "everything" to FLAC, which makes up most of my library.  I have not verified every field.

For me, it's far less effort to do the rename using the MC Rename, Move, can Copy files tool.  It's designed for this task.  It's MC aware.  In fact, RM&C is one of MC's absolute best features.  It's very powerful.  Being a Unix guy, you should appreciate the philosophy of the RM&C tool.  It allows you to do essentially all of the file move/rename/copy operations that you could think of.

There are times when I do large moves of big chunks of my collection.  For example, I recently moved my music from an internal SSD drive to an external spinning drive.  I used rsync to copy the files over.  I did NOT try to use RM&C.  Because RM&C really isn't meant for doing large moves of lots of files.   But once it was done, I did use RM&C in "Update Database Only" mode.

In this mode RM&C simply updated all of the file location pointers in its database to point to the new locations on my external disk.  MC was aware of all of my changes.  But the heavy lifting of shuffling bytes around was handled by another tool.

It's this kind of flexibility which keeps me coming back to MC.  ...and because of this I don't care for solutions where we aren't being explicit.  Like renaming things and then letting MC kinda sorta figure it out. 

I hope that explains where I'm coming from.  You may disagree.  This is simply my approach.

Take care,
Brian.

[afora]

Make sense about not having to do extra work, Brian. I sometimes wonder what an incredible time drain this whole music database management is. So appreciate your approach.

My approach is based on maintaining portability as much as I can, not to be dependent on a single software vendor. Hence everything is stored as file metadata.

Also, when I move/rename anything I rarely tinker with RM&C, rsyncing or just cuting and pasting in a file manager. Main reason is that I never change names of individual track files as I do not care about them relying only on metadata, so the operations usually involve folders or an occassional moving a file from one folder to another.

For that use case it feels doing it in the OS is about 5 times faster than going via RM&C (I'm a keaboard guy too). And yes, I'm very fickle so I like reorganising data as I go A LOT. Then once I'm done I click Auto-import Now, like fixadent-and-forgetit.

Anyhow, thanks for your comments, I do appreciate you sharing your thoughts!