Using Picard v1.2 in Linux. It seems to cut off the title value after 80 characters during saving. The control point shows the correct number of characters. Is picard’s file saving capability limited to 80 characters or do I need to set a special option?
For example the first three titles are cut off after 80 characters.
Picard shows 96 characters for title 1:
Manfred
There’s a max limit on path length IIRC (and that’s a pretty long path). Not sure what it is though!
@LordSputnik has filed an improvement ticket which should help with this:
https://tickets.musicbrainz.org/browse/PICARD-345
The linked issue might also provide some background and more links for even more reading.
Looks like changes were made in Picard v1.3 (http://tickets.musicbrainz.org/browse/PICARD-110). I should have searched the tickets before sending out this topic. Anyway, until my Linux distro takes over v1.3 I’ll find a way around this limitation (it happens mostly for classical stuff). Thanks, Manfred.
The name limit (on each component—file or directory—in a path, not on the entire path) is 255 on most Linux filesystems, including both ext4 and btrfs. There isn’t really a limit on the total length of the path, PATH_MAX notwithstanding.
I just noticed that my saved filenames were being cut off, so I read up a bit and here is what I learned.
Picard 1.3 controls excessive directory path and filename length differently than Picard 1.2. With Picard 1.3, there is a big division between length control if you a) either are running Picard on Windows or have the Picard 1.3 option “Windows compatibility” checked; versus b) are running Picard on Mac OS or on Linux, and have “Windows compatibility” unchecked.
As part of renaming tagged audio files and moving them to their final destination, Picard constructs a file path for the file. The path is the complete sequence of directory names, ending in the file name. Picard constructs the file path starting with the directory path in the options box “Move files to this directory when saving”. It then fills in the tagger script in the options box “Name files like this”, using tags from the audio file, constructing a sequence of directories and a file name, and appends this to the starting path.
Then, Picard forms two kinds of corrections to the file path. It changes any undesirable or forbidden characters in the path to safer alternative characters. It also shortens directory names and/or the file name from the file path if they are too long. The details of these two kinds of corrections can play out according to two cases, the Windows compatibility case and the non-Windows case.
Windows compatibility case
When Picard runs on Windows, or when the “Windows compatibility” option is checked on any system, Picard changes the file path characters in the file path which are forbidden on windows, and shortens directory and file names if needed to comply with Windows limitations.
Picard changes any characters "*:<>?| to _. It also changes any . at the end of a directory or file name to a _.
Picard enforces three limits on the overall file path, and on each directory name or file name in the path.
\ or /, for Windows or non-Windows) as well as directory names./Volumes/Qmultimedia/, then none of those characters are counted against the limit.As of version 1.3, Picard enforces the limits as follows. First, any directory name or file name which is over 226 characters is cut down to 226 characters. Then Picard gives the directory names as much of the overall limit as they need, subject to their own 244 character limit. Picard adds up the length of directory names, after allowing for the tricky details. If they are longer than the effective 244 character limit, then Picard truncates the longer directory names proportionately to their length, until the limit is met. Finally, Picard compares the length of the directory names part of the path to the overall limit of about 255 characters for the entire path. Whatever is left over is what the file name must fit into. Picard truncates the file name by preserving the extension (e.g. .flac or .mp3), truncating the right-hand end of the rest of the filename, and restoring the extension.
All this adds up to Picard quite possibly cutting off file names in order to maintain Windows compatibility. If you have a file naming script like:
%artist%/%album%/$num(%tracknumber%,2) %title%
And if your %artist% is a 292-character behemoth like in this classical Release, then the %artist% will soak up the entire 244-character limit for the directories, and the file will likely end up truncated to the 12 or so characters left in the overall 255-character limit after 244-or-so characters for the directory part of the path is consumed. The track number and leading space take 3 characters, the extension and separator take 4 or 5 characters, so the rest of the file name will will be 3 characters!
To limit %artist% strings a reasonable part of the overall path, start with about 255 characters for the overall path. Reserve a reasonable number for the file name characters (e.g. 80), and enough for the path in the “Move files to this directory” option, and then limit each of the directories in your “Name files like this” option script to a reasonable proportion of the remaining characters. Use the tagger script function $truncate(string,length) for this.
Here is an example file naming script, allowing 30 characters for the “Move file to this directory” option and 80 characters for the filename, leaving about 140 characters for the two directories:
$truncate(%artist%,90)/$truncate(%album%,50)/$num(%tracknumber%,2) %title%
non-Windows case
When Picard runs on a non-Windows system, and the “Windows compatibility” option is unchecked, Picard shortens directory and file names if needed to comply with that system’s limitations. For Mac OS, each directory name, and the file name, must be 255 or fewer characters long. For Linux, the limit on the length of each directory name, and the file name, depends on the specific system, but is likely 255 or more characters.
Further reading
There are many technical details, especially for the Windows compatibility case. Consult the following references:
Thanks for the nice write-up.
Off-topic alert!
Which is IMO a mistake. Yes, all the names are on the cover, but there’s probably a reason why anybody except Harnoncourt and Bach are white on light blue. Most people would have to pick up the CD to be able to read „Pregardien“ … for this purpose it would make no difference if the artist were on the back, and not on the front cover. I’d just list the two prominent artists and be done with it – heed the spirit, not the letter of the guidelines!
That said, you could certainly find other releases where a very long %artist% is fully justified.
Thank you very much for this writeup. I always have to lookup the details because this is an area were we had a lot of tweaks over the years and it is a surprisingly complex issue.
A detail I wanted to mention is that a design goal of the truncation algorithm is that it should create predictable folder names even in case of different length track titles, so a single album does not get scattered over multiple differently truncated folders.
Thank you mentioning this explicitly. Yes, I agree that it makes folder names consistent between tracks in the same Release. It even makes folder names for later Releases by the same ReleaseArtist predictable. I didn’t like how the algorithm left so little room for filenames, but that’s a consequence of it being predictable about folder names before it knows the length of future track names.
I thought this was an OS issue. I wonder when this will be fixed. Has anyone come up with a solution for Windows?
Your problem is an OS issue
See Picard will not tag the full info - #5 by thedeadinme
In your example, Windows isn’t reading the full tag for the album column.
This thread is about file naming, not tagging.
ps This would be an OS issue for you as well anyway, since Windows doesn’t allow very long file names. Linux does, apparently.
Another user told me to use v2.3 tags. The issue is fixed. As long as the names display correctly that is all I care about.
I’m glad there is an open ticket about this. The Windows-compatibility feature is a welcome convenience, but I’ve often wished I could disable the filename truncation.
Just for me to understand: You are not using Windows, but would like to enable the character replacement part of the compatibility mode but keep the file limits disabled?
You are not using Windows, but would like to enable the character replacement part of the compatibility mode but keep the file limits disabled?
You have it exactly. I might copy files or subdirectories to a Windows volume, but I never mount the entire disk in Windows or replicate the entire directory structure.
So if the path is long, the price I pay for Windows-friendly filenames is some ambiguity, like: