I've just repartitioned a hard drive with an extensive collection of MP3s and M3U playlist files that were originally in sub-directories of a \MP3s folder in the root of an E: drive. Because of added partitions, and the fact that some existing partitions were switched from primary to logical, the original \MP3s folder is now sitting on a G: drive.

My problem is that Winamp can no longer locate MP3s pointed to in each of a very large group of pre-existing M3U playlist files that now find themselves nested inside of a G:\MP3 parent folder instead of a E:\MP3 parent folder. This has resulted in a [Valid frame not found] error in Winamp’s playlist window when attempting to play MP3s listed in any of those M3U playlist files.

I've been told in the Winamp support forum that the extended MP3 data format that Winamp uses to code its M3U files should be independent of drive specification. And thus that the drive letter change from E: to G: should not affect the ability of Winamp to locate the MP3 files pointed to in the M3U files on the drive where they were originally created.

But the fact remains that with the new change of the partition drive letter on this system, Winamp can no longer find any of the MP3s pointed to in any of the many pre-existing M3U files.

The discussion on the Winamp support forum can found here.

The system is set up with both Windows 98 and Windows 2000 OSs. With W2K running from D:\Winnt, and the G: drive remapped to a E: with W2K's Disk Management, the problem with Winamp and M3U files doesn't exist. But from Windows 98 running from C:\Windows, Winamp is having problems locating and playing MP3s listed in M3U files from where they're now operating on a G: drive. (It finds none.)

Thanks for any suggestions on just what may be causing the issue, and/or thoughts on how it might be addressed.

IIRC, M3U files are plain text files with paths to MP3s. If it is like that, you could try to load them to some text editor and do automatic search & replace (search for E:\ and replace it with G:\).

Yeah.... as I pointed out on that link to the Winamp forum, the M3U files are in fact simple ASCII files. But Winamp uses some kind of extended data coding for some puposes that I don't remember at this point. But the files don't include the entire paths to the MP3s.

Here's an example where you can see that the root directory, \MP3s has been left out:

#EXTM3U
#EXTINF:247,Dar Williams - Starman
Folk-World\Dar Williams\Dar Williams - Starman.mp3
#EXTINF:229,Bob Marley - Redemption song
Unsorted\Bob Marley - Redemption song.mp3
#EXTINF:268,R.E.M. - Losing My Religion
Rock-Pop\REM - Misc\REM_-_Losing_My_Religion.mp3

The full paths from the root drive for those files leaving out the drive letter as Winamp does should be:

\MP3s\Folk-World\Dar Williams\Dar Williams - Starman.mp3
\MP3s\Unsorted\Bob Marley - Redemption song.mp3
\MP3s\Rock-Pop\REM - Misc\REM_-_Losing_My_Religion.mp3

I've opened a couple of dozen M3U files manually and found that only about 30% of them are missing the full path with the root \MP3s folder. I suppose I could set up a macro that would insert that folder name on every other line of the M3U. But with the hundred odd files to go through, it's still a bit of a task.

At this point I'm wondering why just those 30% odd M3U files had the beginning of the file paths truncated. That may be the crux of the problem. I just did a quick test of copying those MP3s complete with the root directory tree from G: where they are now, to E: where they had been, and loading the M3U file from there. And Winamp fails to load them there too, giving the same error message: [Valid frame not found]

If the root folder characters, '\MP3s' were somehow deleted somewhere along the way, how it may have happened is sure a mystery to me.

Did you try loading these playlists to some other player (foobar2000 or Windows Media Player) and then saving them again?

Yeah... I loaded into FB2K and my favorite tag & playlist program Gearvolt (which I helped beta test, and still think it's the best thing out there for MP3 based tags), and neither can find the files without the root \MP3s folder specified in the path in the M3U file.

Still have no idea how the files ended up missing that folder in the path. And I don't know how long they've been that way, or if Winamp actually ever really worked with them that way. I didn't notice any problems with M3U files prior to repartitioning the drive, and don't see how repartitioning could have been responsible for the same few ASCII characters ti be lost in a large group of M3U files.

How about moving that folder back to E:\, loading the playlists to some other player than Winamp, and saving them again hoping that then the player will constantly save relative paths only or at least absolute paths only so you can do automatic find & replace?

I did try creating the same basic directory tree on E:\ with a few MP3 folders designated in one problem M3U file to mirror the original files now on G:\. But without the x:\MP3s portion of the path in Winamp's M3U files, nothing seems to be able to find those files.

At this point I'm resigned to go in and add the missing ASCII via 'search and replace' on a file by file basis.

Relative paths should work, unless the M3U files are not located in the correct place.

E:\mp3\blah.m3u containing:

#EXTM3U
#EXTINF:247,Dar Williams - Starman
Folk-World\Dar Williams\Dar Williams - Starman.mp3

...should have no trouble locating e:\mp3\Folk-World\Dar Williams\Dar Williams - Starman.mp3, unless the M3U reader does not support relative paths.

I am not even sure if M3U is supposed to support relative paths, but obviously, since something wrote them that way, they are supposed to be readable.

It's got to be some problem with the FAT32 file system on several partitions on this notebook system. I have 2 partitions for dual-booting Win98 and Win2000, and 2 more for data. I have the whole \MP3 folder and sub folders backed up on a desktop system running WinXP, and the exact same M3U file there works fine there with both Winamp and FB2K. Neither Winamp, FB2K or my Gearvolt MP3 tag/playlist editor can access the MP3s designated in that M3U on the notebook.

I have been addressing a problem with the Win2000 installation and partitioning on this old Toshiba Libretto 110CT for a few weeks now. The 110 has crippled Int13 extension BIOS support for hard drives over 8GB. But while its BIOS can't properly see beyond 8GB, OSs like W2K, WXP, Linux and others can work around the BIOS limitation without the need of installing drive overlay. Or so I was lead to believe. But I ran into problems when I 1st assembled the system from parts. While trying to copy files from a <8GB partition to a >8GB partition, the system melted down. I had it dual-booting W98 (for an old TDK W98 only sound card) and W2K, and lost access to both OSs.

Installing drive overlay has addressed the problem of file conflicts between >8GB and >8GB partitions. But I can't help but wonder if something connected that that issue may be involved with this M3U/MP3 problem.