

I'll keep comparing FLPs and post anything else I learn about the format, but at this point I'm just happy I got my shit working again. So if you have a corrupt FLP that has data in it (i.e., you don't have a 0-byte file), this will at least let you open the damn thing.

In any event I'm happy it will only take me a few hours to rebuild the playlist data instead of having to start from scratch. Unfortunately, the Playlist pattern data (how you build different patterns together-don't know the right terminology) was lost, but all the parts are there and all my pattern labels were still on the playlist. This brought back all of my instruments with intact settings, and all of the patterns I had written.

Overwrite whatever two bytes come after "64 74" to get "64 74 55 A1" as the first four bytes of the second line in the file. The next two bytes are the address pointer you just got. The second line (which is always address 00000010h) Must begin with "64 74" on the left (corresponding to "dt" on the text side). microcomputers) store the least-significant byte of addresses first in memory). I don't remember my assembly programming enough to recall why, but these need to be reversed for pointer purposes (EDIT 3: it's because Little-endian systems (e.g.

The last four characters (representing two bytes) are the address we want: A1 55. Add that to the line's address to get 0000a155. Note that there are 16 bytes per line, and this is in hex, so if the byte you're interested in happens to be the last one on a line, its "number" is F. Let's say the end of your file looks like this: There should be several repetitions of "1\" with other characters (if not, the end of your file is hosed and this probably won't work). I imagine that confused FL.Įdit 2: to get the correct pointer address (see Edit 1), look at the end of the file. So what happened in my case was that the pointer to the "end" of the file was really pointing to the very first byte, before the start of data. With such small files it works, I guess, it's just weird. I believe this is due to the really sloppy way FL handles files.instead of putting a pointer to various sections (i.e., "go to this address for instrument data this one for pattern info etc.), FL just crams information in and the program has to scan for headers to find various sections. My corrupt file had nulls in the 19th and 20th bytes of its header, so I overwrote them with data from another FLP header.Įdit: it turns out those two bytes are a pointer to an address 22 bytes from the end of the file, consistent among all files I looked at. Additionally, the first two bytes of the second line (64 74 bytes 17 and 18 of the header) are exactly the same in all files, but the third and fourth (B1 77 above) are not consistent even in files saved from the same version of FL. The second line is similar, but the last half contains the FL Studio version number (5.01 in my case, as seen on the second text line above). The first line is exactly the same in every FLP I looked at. A google search found nothing other than forum messages like "you're fucked. Long story short, it was a corrupt file (verified by trying to open the FLP on another computer). It may be corrupted, or some plugin caused an error while opening." "An error occured while reading the FLP file. When I restarted and tried to load my song I got this: I hit save again (FL was still running, it just stopped making sound) to be sure everything would be OK, and closed the program. If that doesn't work for you and you don't mind getting your hands dirty, continue:Īfter working on a remix for about 30 hours, I tried to load a VST effect which crashed FL Studio right after a save. Now back to our regularly scheduled post.ĮDIT: Steve Laboy has come up with a more elegant and (more importantly) easier way to fix corrupted files here: If you came here from a google search on corrupt FL files and couldn't be bothered to read the entire thread, at least read this part: I WILL NOT FIX YOUR FILE FOR YOU.
