My two cents, path+file name
Your X=
should be 244 characters (255 characters if using UNC paths, actually more using really long paths as ferday mention, but that's for Glynor or ferday to explain
).
As Tao said correctly there is a 260 character limit (Maxpath) imposed by Windows OS.
Item(s) | Maximum number of characters | Comments |
All components together including null terminator D:\somefolder\somesubfolder\somefile.extension{nul} | 260 | Limit imposed by Windows OS |
All components without null terminator. (Disk or volume plus folders plus file) D:\somefolder\somesubfolder\somefile.extension | 259 | Actual limit since null terminator always uses up one character. |
All folders plus file somefolder\somesubfolder\somefile.extension | 256 | Number left after allowing three characters for disk or volume name. |
File somefile.extension | 255 | Limit imposed for any one object . Practical limit likely to be less unless file is in the root directory. |
All folders somefolder\somesubfolder\ | 244 | Limit for folders imposed by the need to reserve characters for alternate 8.3 short names for files. |
Using 64bit system you can avoid the 8.3 penalty but you might have issue playing back or manipulating files on 32 bit systems. UNC paths+file would be 255-3 for the drive volume or max 252 characters.
Secondly It´s better to use UNC than a mapping character, use the name of your NAS (or SAN)
I don't totally agree on that for JRiver use. If you have a server/client set-up where the server is a PC and not a NAS, I find it better to map the drive to a lettered drive. If you have a NAS, sure go unc. Everything else I agree with though lawe
Regardless it is often in classical music where you scape these really long file names when ripping. Probably because the original guys who took the time to tag an opera manually where used to using the file name to choose their music directly from windows or tree set of folders. That's a bit medieval now. On top of it it players there is never enough space to actually read the album and track name
Most of the OPs filename should be in the metadata and not in the file -- like the life span ?? of I presume the composer??!! Another reason why the FLAC container is so cool, it holds as much detail as you want.
IMO, but shared lots of people is you want a file structure to enable rebuilding a messed up library that would also allow you to find it in a web search if necessary. SO you need the album artist, the artist (for compilations) the track number, the track name the disk number, and the album name. With classical often you find the last name of the conductor in brackets. You don't repeat anything.
so the OPs long file name
E:\Media Server Directory\Music\Assorted Albums\Concertos for Double Bass & Orchestra (Zsolt Fejervari, double bass; Erkel Ferenc Chamber Orchestra)\01 - Vanhal, Jan Krtitel (1739-1813) - Concerto for Double Bass & Orchestra in D major_ 1. Allegro moderato.mp3
could be something like this (or a UNC version of course)
E:\Music\Vanhal, Jan Krtitel\Concerto for Double Bass & Orchestra in D major[Ferenc]\1. Allegro moderato.mp3
(+ the artist name for compilations)
you could even add a "Classical" to the path and you would still be at half the number the OP was before. Some people do add a date to differentiate versions in classical, but again that can be in embedded tags too. Lots of ways to do it, as long as it is consistent
Long file names can provoke other problems too. I have found lots of my long file names (that still exist cause I'm lazy), are truncated or have timing errors. They play, they import, they are under the limit (barely) - but some of the song is missing^^
I hope that JRiver keeps the shell limit or even reduces it some.
http://vlaurie.com/computers2/Articles/filenames.htm http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath