Print

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

[Peter Engrav]

I have, for example, a track who's filename is ...

\\Files\Music\[Fiction]\The Chronicles of Narnia #1 - The Lion, the Witch and the Wardrobe\001.Forward.flac

Having installed MC17 last night and then done a little messing around with some track names I tried using Rename, Move, & Copy Files and was surprised to see that even with no changes on such tracks, MC intended to rename them to as ...

\\Files\Music\[Fiction]\The Chronicles of Narnia #1 - The Lion, the Witch and the Wa\001.Forward.flac

The rdrobe at the end of the (longish) directory name had been chopped off.

This is actually sort of dire. If I were to update some track names and then do a huge "please rename all the tracks correctly" as is my wont (MC having demonstrated over time that it bascially never screws up and does something random) now suddenly I'm scared that things will go wonky. Ihave other music systems (Sonos, for example, and some other links) so unintended file renames are a big scary. I suspect they might also mess up the next backup pass (suddenly lots of "new" songs and lots of extraneous data).

For now I had to go back to 16.

[MrC]

There was a change in MC17 to limit the expansion of a single field to 60 characters.  This was to solve one problem.  But it introduces uncertainty in the ability to reliably use Fill Properties from Filename.

There is a discussion in a different thread about this, but no follow-up yet as to possible resolution.

[Peter Engrav]

I failed to find the other thread. Link?

[JohnT]

We're currently doing some more thinking on how to improve the situation.

[MrC]

I didn't post the link, as it was in the beta forum.  I've made that mistake too many times. ;-(

[JohnT]

I made the mistake this time 

[flac.rules]

So no fields in the tag can be longer than 60 chars now?

[MrC]

The fields can be arbitrarily long (essentially).  It is within the Rename operation that they are truncated, on a per-field basis.

[Frobozz]

I discovered this new behavior when importing a classical CD.  Fields with classical music can get quite long.

My concern would be unexpectedly ending up with two directories named the same after a move/rename because the first 60 characters of two CD titles happen to be the same.

For example.  If I had a directory naming scheme with "\[Album Artist (auto)] - [Album]"
And two CDs with the Album tags
12 Concertos, Op.8 (including The Four Seasons) (Monica Huggett) (Disc 1)
12 Concertos, Op.8 (including The Four Seasons) (Monica Huggett) (Disc 2)

I would end up with both discs getting renamed/moved into the same directory
Vivaldi - 12 Concertos, Op.8 (including The Four Seasons) (Monica Hugg    <---  chopped at 60 characters

That's an actual Album title from my library.

I can work around that by adding an additional field to the end of the directory that would guarantee uniqueness.  The issue is I wasn't expecting it to get chopped at 60 characters.  That's new behavior I wasn't expecting.  Maybe some sort of alert in the move/rename dialog when a field gets chopped at 60 characters would be helpful.