Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Cue sheet problem--Path is too long? (Read 5364 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Cue sheet problem--Path is too long?

I'm using fb200 on a Windows 7 64-bit system.

It is unclear whether cue sheet file (.cue) handling is core technology or plugin/addon, so I'm posting here. fb2000 chokes on most of my cue sheet files.
The cue sheet files were created automatically by EAC (Exact Audio Copy). One reason is that EAC for some reason tags .flac files as .wav files in the CUE
sheet file. I can correct this problem with manual editing. The other problem is that fb2000 seems to fail if the path to the file is greater than a certain length.
If the audio files/cue file is deep in a nested tree (eg <long directory name 1>\<long directory name 2>\...\<audio files>, fb2000 indicates there are index errors
in the cue file. If I move <audio files> closer to the root, the errors go away.

My path lengths are less than the Windows non-extended length maximum MAX_PATH = 260 characters, and I can perform operations on the files using Windows
Explorer and other utilities.

To avoid path length problems under Windows, use the extended-length path syntax described here:
http://msdn.microsoft.com/en-us/library/wi...5).aspx#maxpath.
If you use this syntax, path length can be up to 32,767.

Can you tell me what fb2000's max path length is when processing files referenced in the cue file, and what happens when this maximum is exceeded?
If you are not going to fix the problem, it might be a good idea to at least flag it with proper error reporting.

Thanks for your help,
MumblingFumbler

Cue sheet problem--Path is too long?

Reply #1 –
Quote from: MumblingFumbler on
It is unclear whether cue sheet file (.cue) handling is core technology or plugin/addon

Core.

Quote
EAC for some reason tags .flac files as .wav files in the CUE sheet

I can't help you with the path length issue, but I can explain that.

First, EAC does not rip directly to FLAC. It rips to .wav and then passes that to an external encoder (or else through a Windows ACM codec library). EAC doesn't know what the format of that external encoder's output is, so when generating the cue sheet (which is basically a separate function from the ripping), it just writes the filename in the cue sheet as whatever.wav, with type WAVE.

Second, although you sometimes see cue sheets that have been modified (or written by some app other than EAC) to say whatever.flac instead of whatever.wav, the type will still be WAVE. The reason is this: Cue sheets aren't standardized, nor were they ever intended to be used as playlists. Rather, they were just designed to help two of the earliest pieces of CD-burning software (Goldenhawk's DAO.EXE and CDRWIN) write data from arbitrary files onto a CD-R. The cue sheet says, among other things, what type of tracks to write (AUDIO, DATA, CDG, etc.), the location of files containing the data, and what type of files they are. The types aren't inferred from the file name or contents; it has to be declared. When you've got a track of type AUDIO, you can only declare the file format as WAVE, AIFF, or MP3. Modern software that utilizes cue sheets that reference .flac files may not care what the declaration says and will just infer a type, but since the only "allowed" types are those three, .flac and any other lossless file types are just called WAVE; it's close enough and doesn't really affect anything.

Since I move files around from where I initially rip them to, I'm in the habit of stripping any leading path components from the FILE lines of a cue sheet, and I just put the cue sheet in the same folder as the files.

Cue sheet problem--Path is too long?

Reply #2 –
The path length issue is because of a limitation of NTFS. NTFS can only have paths of 255 character length max. Since you say moving it closer to root fixes the .cue, that's the reason.

Cue sheet problem--Path is too long?

Reply #3 –
Quote from: ChronoSphere on
The path length issue is because of a limitation of NTFS. NTFS can only have paths of 255 character length max. Since you say moving it closer to root fixes the .cue, that's the reason.


No, you are incorrect about NTFS imposing the limit. If you'd read the MS reference that I posted, you would have learned that. Some of the
Windows API have this restriction, but there is a workaround using extended-length syntax, also spelled out in the MS article.

Another article stating the same facts:
http://msdn.microsoft.com/en-us/library/aa365247.aspx

Cue sheet problem--Path is too long?

Reply #4 –
Quote from: mjb2006 on
Quote from: MumblingFumbler on
It is unclear whether cue sheet file (.cue) handling is core technology or plugin/addon



Since I move files around from where I initially rip them to, I'm in the habit of stripping any leading path components from the FILE lines of a cue sheet, and I just put the cue sheet in the same folder as the files.


The paths are not part of FILE designation--they only contain the filename. FB2000 must normalize the filename into a complete path as part of its .cue file processing. This must be what is causing the error.

Cue sheet problem--Path is too long?

Reply #5 –
Quote from: MumblingFumbler on
Quote from: ChronoSphere on
The path length issue is because of a limitation of NTFS. NTFS can only have paths of 255 character length max. Since you say moving it closer to root fixes the .cue, that's the reason.


No, you are incorrect about NTFS imposing the limit. If you'd read the MS reference that I posted, you would have learned that. Some of the
Windows API have this restriction, but there is a workaround using extended-length syntax, also spelled out in the MS article.

Another article stating the same facts:
http://msdn.microsoft.com/en-us/library/aa365247.aspx
And who says this workaround was implemented (in foobar2000)? You can keep insisting the path length isn't the problem, but that doesn't change the fact moving the files up solves it as you said yourself. Fact is, the default way of referencing the file is limited to 255 characters (260 if you count the invisible <NUL> terminator). Actually, I know of little to no programs that reference files using the \\?\ prefix internally. I code now and then myself, and this is the first time I heard about using \\?\ in file path names.

Cue sheet problem--Path is too long?

Reply #6 –
foobar2000 actually uses the extended syntax, probably has since beginning. I can't replicate any cue sheet opening misbehavior with the description given in the first post. I created a several directories deep path that became 242 characters long. I placed files and cuesheet in this location and I could open them fine. The path length combined with file name lengths exceeded 260 characters which seems to trigger Explorer to give foobar2000 8.3 format short names when opened through it. I then tested opening the same cue sheet from command prompt using the extended length syntax to get real full name without shortening. That opened fine too and file properties verified that full name was in use.
If there is a problem then more info how to trigger it is needed.

Cue sheet problem--Path is too long?

Reply #7 –
Quote from: Case on
foobar2000 actually uses the extended syntax, probably has since beginning. I can't replicate any cue sheet opening misbehavior with the description given in the first post. I created a several directories deep path that became 242 characters long. I placed files and cuesheet in this location and I could open them fine. The path length combined with file name lengths exceeded 260 characters which seems to trigger Explorer to give foobar2000 8.3 format short names when opened through it. I then tested opening the same cue sheet from command prompt using the extended length syntax to get real full name without shortening. That opened fine too and file properties verified that full name was in use.
If there is a problem then more info how to trigger it is needed.

Thanks for your investigation. Perhaps my analysis is wrong. I'll try to narrow down the problem. My conclusion was based on the behavior that if I moved the folder containing the audio files and cue sheet file up in the directory tree closer to the root, the errors went away and the cue file was processed correctly.

The audio file folder containing the cue file was on a server (eg. \\<server name>\<server drive>\<directory 1>\...\<directory n>\<audio files>), and fb2000 was initiated via a 'Open With' on the cue file from Windows Explorer. No single path segment is longer than 255, and Windows Explorer doesn't have a  problem with the audio file folder.

Cue sheet problem--Path is too long?

Reply #8 –
You didn't mention that it's a remote location initially. Anyway, similar long path accessed on NTFS over a network share performed the same short name transformation and everything worked fine. But trying to access the cue with full path names without triggering the shortening seems to be impossible. Apparently foobar2000 doesn't support the \\?\UNC\ syntax. Then again I didn't succeed opening the file with the full name with any other program either, except a test program I wrote myself.

I also tested the behavior after I disabled short 8.3 name creation and re-created the long directory structure. At this point Explorer becomes useless and it can't do anything for the cue sheet, including opening it with other programs.

Cue sheet problem--Path is too long?

Reply #9 –
Quote from: Case on
You didn't mention that it's a remote location initially. Anyway, similar long path accessed on NTFS over a network share performed the same short name transformation and everything worked fine. But trying to access the cue with full path names without triggering the shortening seems to be impossible. Apparently foobar2000 doesn't support the \\?\UNC\ syntax. Then again I didn't succeed opening the file with the full name with any other program either, except a test program I wrote myself.

I also tested the behavior after I disabled short 8.3 name creation and re-created the long directory structure. At this point Explorer becomes useless and it can't do anything for the cue sheet, including opening it with other programs.


I don't think the fact that the cue file resides on a server has anything to do with the problem. It just tends to make the path length longer.

It would be nice if FB2000 correctly processed any .cue file that could be visible in Windows Explorer, and opened by say, notepad (or even opened in FB2000).

Here is the case where that doesn't work:
.cue file path:
\\xxxxxxxSERVER20\xxxxxxx Server D\Downloads\xxxx xxxxxxxxxx\[Music--Other]\Alison Krauss - A Hundred Miles Or More (A Collection) [2007] [xxxxxxxx] FLAC-EAC\Alison Krauss - A Hundred Miles Or More (A Collection) [2007] FLAC\A Hundred Miles Or More.cue
Path length = 252 characters
I can see this file in Windows Explorer and edit it using notepad.

Here is a fragment from the start of the .cue file

REM GENRE Country
REM DATE 2007
REM DISCID D80FD910
REM COMMENT "ExactAudioCopy v1.0b3"
FILE "01 - Alison Krauss - You're Just a Country Boy.flac" WAVE
  TRACK 01 AUDIO
    INDEX 01 00:00:00
.
.
.

path length + filename length = 278 characters.

And I can even open this first track in FB2000 from Windows Explorer using <right click> Open With...!

Here is the error that FB2000 gives:
Unable to open item for playback (Object not found):
"\\xxxxxxxserver20\sxxxxxx server d\Downloads\xxxx xxxxxxxxxx\[Music--Other]\Alison Krauss - A Hundred Miles Or More (A Collection) [2007] [xxxxxxxx] FLAC-EAC\Alison Krauss - A Hundred Miles Or More (A Collection) [2007] FLAC\A Hundred Miles Or More.cue" / index: 1

No indication that there is path length problem.

There are programs that handle long path names correctly
Here is one:
http://www.tgrmn.com/web/kb/item31.htm

And, agreed, most do not.

The real problem arises when you share data with Linux and Mac OS users, who structure their folder/filenames without these constraints. Shortening names in Windows becomes a real pain.

Cue sheet problem--Path is too long?

Reply #10 –
Using Long Path Tool or other means to rename the files or directories would be a workaround. Long name support for network shares is already included in the next foobar2000 version. User just needs patience to wait for the next release.
 

Cue sheet problem--Path is too long?

Reply #11 –
MumblingFumbler, the beta with long UNC path support is out now. Please test and report if you find issues.