Everything we love about Samplers from E-MU, AKAI, Ensoniq, Kurzweil, Korg, Roland, Yamaha, and all the rest.
You are not logged in.
Pages: 1
I've recently updated my E6400 Ultra to EOS 4.70, mostly because I wanted the FAT option. I started messing with file transfers and, just when I wanted to save a bank on my internal HD… the disk was empty! Totally blank, with just a "Default Folder" inside. At first I thought I had mistakenly initialized it while messing with my zip drives (but I was formatting FAT zip's and my internal HD was still in E-mu Filesystem, and I would've probably noticed some unsual formatting times…) but then, someone on Facebook's EIV page told me it was a bug in EOS 4.7 where your drive could be wiped if you named a new folder on it while creating it (actually, the solution is to first create a folder with its default name, and then rename it afterwards). And that's probably what I did.
I wouldn't say all my musical life was on this hard disk, as it mostly contained factory E-mu banks and some stuff I had imported (most of my personal samples are on Esi-32 zip's)… But I hate the feeling of losing everything like that and I know the data is still there.
Now, I'm not trying to verify if this bug is really what it is (although it would be cool if it could be officially acknowledged) but I'm trying to find a solution to recover my drive. The thing is, E-mu filesystem is not something that mainstream data recovery software will know and I'm a bit lost…
I took the hard disk out of the sampler, connected it to a usb-to-IDE adapter. I have access to a Mac (Mac OS X) and a PC (Win10).
Any suggestions?
Offline
That's bad news Have used 4.7 for many years but never had this problem... will think twice next time I'm creating new folders just in case (although I always use FAT so maybe that's why). Not much help but fwiw - Chicken Systems Translator on Win PCs is one tool (might be others) which understands EOS file structure; not sure if it has diagnostics for fixing discs though. Good luck.
Update: have just tried to recreate the problem on a spare IDE disk. Tried both formats E-mu and FAT, and creating/renaming folders seems to work ok. Can you remember exactly what you tried?
Last edited by philtipping (2015-12-13 15:21:44)
Offline
If you can take a disk image of the drive then I have analysed the EMU3 file format and might be able to recover the files if parts of the folder structure have gone missing.
Offline
That's bad news Have used 4.7 for many years but never had this problem... will think twice next time I'm creating new folders just in case (although I always use FAT so maybe that's why). Not much help but fwiw - Chicken Systems Translator on Win PCs is one tool (might be others) which understands EOS file structure; not sure if it has diagnostics for fixing discs though. Good luck.
Update: have just tried to recreate the problem on a spare IDE disk. Tried both formats E-mu and FAT, and creating/renaming folders seems to work ok. Can you remember exactly what you tried?
I can't remember exactly what I did. I remember updating to 4.70, booting in 4.70… I remember formatting a zip disk as FAT (took longer than E-mu formatting), then transferring banks on that zip from my PC, loading a bank from the zip in the Ultra… And then when I wanted to save it on the Ultra's internal drive, noticed my drive was blank with only one empty "Default Folder". Then someone on facebook EIV page told me about that possible bug in OS 4.70.
I temporarily reverted to OS 4.61, hoping for a miracle… but it didn't change a thing.
I don't know if Chickensys would see the drive. Maybe it would, but the real problem is that the drive's catalog has obviously been wiped so I doubt it sees any files on it.
If you can take a disk image of the drive then I have analysed the EMU3 file format and might be able to recover the files if parts of the folder structure have gone missing.
You mean YOU could analyze the disk image and potentially get the files back?
Offline
You mean YOU could analyze the disk image and potentially get the files back?
If it's in Emu format, yes, I could certainly attempt to read the files, or at least confirm that the FAT structures are toast. I have code which will read this disk format (EMU3) and I could hack it to try to work around missing data.
If the volume is FAT32 then conventional tools could be used I think.
Martin
Offline
Okay. Well, no, the volume is not FAT32, but E-mu format. I made an image of my drive with Stellar Phoenix, but it's approx. 18Gb. How would I transfer that?
I just discovered that ChickenSys Translator actually had a E-MU DISK FIX function… But it keeps crashing here. Founds a "block at 124" and then the program crashes and shuts down.
Offline
I also made an image of the drive on my Mac, but it turns out to be only 5 or 6Gb… ???
Offline
I think the first few 100 MB of the image would be enough to 1. Find out if the file allocation table exists and 2. Work out block sizes. At that point I could give you the software to try with the whole image. This would need to be part of a raw image btw .dmg is what OS X will give you by default. I would think a tool to read the first portion of a file to another file must exist, but easily written if necessary.
Offline
PS I'd suspect that any Translator function to "recover" a disk is likely to make matters worse!
Offline
Sorry for the (two year) delay… I ended up adding a bigger drive in my E6400, FAT formatted, and decided I would only load it with Emulator/Emax banks, as I don't really need the more generic late 90's stuff. The former drive has been stored, untouched, just in case we find a solution. Thanks for your time ;-)
Offline
Pages: 1
[ Generated in 0.021 seconds, 10 queries executed - Memory usage: 1.61 MiB (Peak: 1.83 MiB) ]