ACCLAIM'S complete file archive rescued

I just redigged an old 256 MB PC2100 DDR 266 Mhz RAM stick.
If you want it, you can have it. Message me Kev!

 

Make sure you back everything up before putting it online. Obvious really, but worth pointing out none-the-less!

 

Damn your avatar confused me. Thought you were Yakumo :lol:.
Anyway get the some excel sheets ready, make loads of folders. Make labels that can be
attached to cd/dvd boxes with ID's one them.

I'd start with making an overview of the contents every disc/hardware item/disk.
Give everything an id and enter the contents (amount of files, total data size, platforms
included) of it in Excell. Or better; in a database.

 

some kind of database would be needed i think too also a timetable or so

torrent isnt the right tool here i think since its 3tb at all splitting it down hmm hard work

a project with kinda the same target is the mame project i think they havent reached more then 100gig of data at all but since there data is comparable in numbers to ours maybe we should look into how they organize there stuff ?

 

:lol: same here!

A database would suit the need better, even for later researchings.. problem is that you dont know what you have in hand up to now, so you dont know how to modell the DB on it...I would suggest starting at first with some excel / file catalog in general and then later move on a DB. I can help with the DB programming!

Managing large data ammounts is normally done top-down, which means you will need to do some cataloguing at first, like splitting up the whole data chunk you have based on some kind of index, on which you can then refer on it for later communication. Still, this approach requires that you somehow know what's on the HDD, which is obviously not the case here...So its still min two turns on the 3TB of data, the first for exploration, the second for catalog.
So I would suggest you to catalogue on content-independent properties (like for example HDD size, manufacturer etc) first, then, on the second turn
we can get deeper in detail.

Possibly CVS could help you keeping trace of everithing what is being examined?

 

If you wanted to go OCD on it you could buy some barcode labels and go nuts with that. Extra mile with anti-static bags and some sort of physical organization system. I can't imagine how much physical stuff you must have.

 

i suggest starting from disc to disc and sharing slices or folders between volunteers maybe...

after a really RAW and fast sorting maybe creating a more organized database....

 

I would hope that they had some form of sensible backup routine, and therefore the tapes etc. are sort of logical, e.g. should contain one (part of a) project on a tape. How large is each tape?

I'm assuming you're using FTP for this? You mentioned that each person's area would be private - obviously this is easy via FTP. It would make sense, as I believe you suggested, to keep things simple by taking one of each physical media and assigning that to a person - unless of course it is a multi-part archive spanned across many tapes! If you can do it per tape, dump each tape into logical folders (e.g. Tape 1, Tape 2), then pop a 'tape' into each user's folder for them to be working on. Pretty logical stuff so far, so I am sure you've already thought of that.

Yes, a database sounds good - so again, some kind of access to the database (but probably again limited per user) to record findings. For now, I guess we need to list sensibly and methodically, in order to determine what information we want included in the database.

Perhaps we could start with a complete tree listing, and then see exactly what type of files we have, and give some kind of brief summary of the files we can identify.

It would be logical that certain types of files need more information than others - e.g. Office documents are straightforward, but may relate to other documents, whereas code could have more complex relationships (e.g. different builds).

Perhaps it would be a good idea to have some kind of wiki on the server? Maybe for now (and throughout the project), it would be interesting to also run some kind of blog software on the server, too. We could then list our finds day-by-day, and keep up with each other's projects.

Anyway, I'm happy to give some time to the project! As you know, it was something I was looking forward to anyway when I was going to buy the DATs off you... I think the teamwork could make this even more fun!

 

Maybe you should set up some rules/guidelines for how you want the data sorted/documented/categorized so the sorting is consistent.

 

What about WebDAV for sharing out the files from the server? Easy setup and WebDAV clients exist for all OSes. It can allow for setting permissions, versioning, etc. Not the speediest thing in the world, though.

Also, I'm questioning how well 768kbps upload on your end is going to handle multiple users download a large amount of data. You're looking at a max of about 90-95KB/s at that speed. With 10 users connected at once, we'll max out at around 9KB/s if we're lucky. Not every fast or efficient for such a large amount of data to be processed.

I also may have an IDE DVD-ROM drive or 2 if needed...let me know.

 

Agree totally on the blog idea. But wouldnt that cover the wiki part as well?

 

It would probably be a waste of bandwidth setting up the blogs on the server. We could just have a sub-forum here where people update a thread like a blog.

Would relieve some stress from the main server.

Organizing the data though....thats a toughy. Depends on how you wanted the end product to look.

A rough idea would be :

• Platform
  • Game Name
    • Build Number/Date
      • Art
      • Code
      • etc...

But that would only really work for a hieracrhical ordering of information. Not really about archiving it.

It may be an idea to collate gathered information once we have had a chance to examine some of the files, then from that agree on a boilerplate archiving for certain resources (code, art, tools, etc..).

In a operation as big as this, with so little idea of what we may come across, I think its best to hold off on a database. We need an understanding of the information before we can break it into the data we want to hold

 

I went away and had a bit of a think on it all last night.

Depending on how serious people are going to take this, it may be an idea to step up management to something a bit less formal than blogs.

Don't worry, I'm not suggesting we all draw up Gantt Charts or anything! I was actually thinking we could easily adapt a Scrum approach to this.

Rather than explaining it all, Here is a Wikipedia link Covering most of the details.

Obviously it would take some adjustment to fit, but I think it would work. Thoughts?

 

personally i consider a less flexible approach better on the long run, for people usually get slow and lazy in progresses after the initial enthusiasm... but i think i'll adapt to any metod anyway...

 

I can agree with that, I just think if we go too strict, people may feel too much pressure and opt out of helping at all. An inbetween would be nice.

 

True. And what about sharing some ssh terminal / RDP connections to the server? If its powerfull enough, it would free us from the whole file download, and with the ADSL bandwidth it would surely work fast enough for everyone.

The idea on the organizing (as you stated and me before ) works only if wou already have an idea of whats in the files. We need a more practicable approach since (as I suggest) we dont have a clue of what lays before us up to now.
A time / media type ordering for example would be a good first-level approach methinks, a little too generic maybe but good for a first look. There are many possibilities for such an ordering, shouldnt be tied forcedly to time or media type, but it should be somewhat context (aka content)-independent for the first approach. That would help us keep an overview and orientation.

In the meantime the knowledge about the contents will grow and it will be possible to get a more precise (possibly final) end ordering...ín my opinion at least.

As for the wiki/SCRUM, that would surely help!

 

Well, yes and no. I guess I didn't differentiate very well, really.

The blog would be the start - basically to report things perhaps informally, so we can all read up on each other's progress - and perhaps say, "Hey mate - I think I have part of what you're describing here!!". So it would be a standard blog, a la Livejournal or whatever. I'm not really suggesting that be THE archiving method, more informal banter between each other. It could look something like this:

Monday: Disc no. 1. File contents from 1998. Found some pictures, seems to be WWF material. There are some code files, looks like C++, will need some help identifying those.

Tuesday: Cracked on with Disc 1. Found some WAV files. General sound effects, crowd noise mostly.

That's just an example ;-) And we'd have our own user names (suggest the board names to avoid confusion!!). Of course, it doesn't HAVE to be on the server. In fact, I could probably spare some bandwidth towards that.

As for the wiki, that would be more final information... well building it. Perhaps someone finds some files for a WWF game, they create a wiki topic WWF and list their findings (e.g. build version). Someone else can then come along and say what's different in another build.

So there we have two methods of looking at what each other is doing - basically per user and per project. Rather than being the final archival method, I'm suggesting this merely as a way for us all to keep up with each other, really.