.M3U files?

[dlanor]

One important thing seems to affect SMS 2.0 - Slashes!

It seems the direction of slashes in relative paths can stop the m3u file from working. Windows defaults to forward-slashes "\" while the PS2 seems to like back-slashes "/".

Please try to use correct terms.
Backslash == '\'
Forward slash == '/'

Windows uses backslash as path separator, but many other operating systems use forward slash for that purpose. Those include Unix and Linux, as well as most of the device drivers for the PS2.

I had a bunch of attempts to get m3u files working with relative paths. Nothing was working when the m3u file was located outside of the directory where the mp3 files resided.

I changed the Windows "\" to the PS2 "/" in all my m3u files and hey-presto! Working m3u's!

Yes, of course. It always helps to use the native path syntax of the target system.

Note: I've been using the ExecFTP Server to transfer the files to the PS2, and the FTP Client (FlashFXP) was treating them as binary, not ASCII. Not sure if this would automatically convert the slashes for me...

It would not. Whether binary or ASCII, the FTP client and server programs have no idea what the purpose of a backslash or forward slash may be, as it could be a part of a normal document. It would be a serious error for any such program to modify such characters, even when dealing with a known ascii file.

Best regards: dlanor

[bladeanon]

Please try to use correct terms.
Backslash == '\'
Forward slash == '/'

Windows uses backslash as path separator, but many other operating systems use forward slash for that purpose. Those include Unix and Linux, as well as most of the device drivers for the PS2.

Sorry - my bad - I got that the wrong way round, I have a lot to do with both Windows and UNIX/Linux systems, I should have known better - typed it up in a hurry.

Thanks for the correction.

Yes, of course. It always helps to use the native path syntax of the target system.

Well in this case with SMS 2.0 it was necessary. I can't understand how people could get their WMP and Winamp generated m3u's to work with SMS. I would assume WMP and Winamp would default to the Windows backslash "\" when generating full and relative paths in a m3u file? Unless enforcing the PS2 forward-slash "/" is newly introduced in SMS 2.0? Or, it's WMP 11.0 that changed it's ways?

It would not. Whether binary or ASCII, the FTP client and server programs have no idea what the purpose of a backslash or forward slash may be, as it could be a part of a normal document. It would be a serious error for any such program to modify such characters, even when dealing with a known ascii file.

I know BIN and ASC modes convert end-of-line characters for you in ASCII files, though I have seen and used intelligent FTP clients (written in Java) that can interpret relative paths within a text file and convert them for you. Though this functionality needs to be switched on manually. Not available in FlashFXP unfortunately.

Thanks!

[dlanor]

----- snip ----- re: SMS needing conversion from '\' to '/' in M3U files

Well in this case with SMS 2.0 it was necessary. I can't understand how people could get their WMP and Winamp generated m3u's to work with SMS. I would assume WMP and Winamp would default to the Windows backslash "\" when generating full and relative paths in a m3u file?

You're right. I never could make those files work right, so I stopped trying. Instead I generate my M3U files by different means. I've made some batch files that use the command line interpreter to generate filtered directory listings, and which also edit those listings with 'sed' to produce a kind of M3U file that both WMP and SMS will accept. (WMP accepts forward slashes too, even though it won't create them.)

This way I can simply drop a folder onto a BAT file and have it generate an M3U file that includes all MP3 files inside that folder (and all its subfolder levels), in a form that both WMP and SMS will accept. Alternately, I can drop a file instead, to generate a similar list for all MP3 files in the folder containing that file (including all subfolders). And in both cases the generated M3U will appear in the same directory where the 'dropped' object was picked up.

The main drawback of this method is that SMS insists on reading the duration of each MP3 only from the M3U file, instead of taking the correct value from the MP3 file. Since the #EXTINF entries in my M3U files are partly faked (my batch can't really evaluate MP3 durations), SMS will display maximized duration values for all songs when playing these M3Us.

Btw: I've always considered it a bug that the optional #EXTINF entries are required by SMS to accept an M3U file, and an even worse bug that its contents are used in preference *above* the proper data in the MP3 file. The #EXTINF duration value only exists to allow simple presentation of durations in song browsers etc, without having to open each MP3. Using the #EXTINF value for any other purpose, like showing it during playback, is a serious error. For such purposes the real value from the MP3 should always be used. Fortunately the incorrectly displayed value is not really controlling the duration though, so the next MP3 in a list will start normally when the current one ends, regardless of the maximixed duration display.

Unless enforcing the PS2 forward-slash "/" is newly introduced in SMS 2.0? Or, it's WMP 11.0 that changed it's ways?

No, I think they've both been the way they are all along, when it comes to path separators.

I know BIN and ASC modes convert end-of-line characters for you in ASCII files,

Yes, and that is appropriate, since the meaning of a line-ending sequence is identical in all real text files. But the same can not be said for any 'visible' characters such as '/' and '\'. The '/' character, for example, will frequently be used in mathematical formulas where replacement with '\' makes no sense at all. And if that text file happens to be program source code it may even cause serious errors in later compiled executables...!!!

though I have seen and used intelligent FTP clients (written in Java) that can interpret relative paths within a text file and convert them for you. Though this functionality needs to be switched on manually.

Even as a non-default option I see it as quite inappropriate. IMHO, such text changes are better done with tools intended for such purposes.

Best regards: dlanor