Unbelievable

[Ian]

Evertime we break our highest scores or add a save game file, we'll have to send it to TOSEC, so they can verify and add it to their list.

I'd very much like to see.

Monkey_Island[cr][IanCharge](disk 1 of 4).zip and so on

BTW I am being facetious, in case you didn't know

[icycool]

Ok, just to clear up a few points regarding renaming Amiga images.

TOSEC is currently limited in its detection of Amiga images as it only works on the CRC of the full 880k image. This is quite adequate for rom based images, however Amiga disk images are a very complex deal.
Ideally to properly catalog a disk, the given disk needs to be stripped down to its component files, checked against a master template for that image, have files that would change eg. (highscore, saves and config files) excluded and see if you have a positive match.
It would be nice if it were all so simple.
What about if you have extra files left on the disk, that don't belong in the template or the exclusion mask?
What if its a hybrid dos/non-dos disk with a nice intro on boot-up.
All these things could be lost in the blink of an eye if u just scan for a full match in the template file.
The only real and lossless way to do it is to detect everything on a disk, excluding only files you know will change.
There are a few other intricacies involved in this, but i'm too lazy to type in a detailed account as ths scanning technology does not exist yet

Now, in response to the LFN PeeCee vs 30 char Amiga limit.
As you may guess by now, TOSEC is limited only by its software (which doesn't do a great deal at the moment ..ahem) and we try to put as much information in the filename as possible. Any extra information we cannot realistically put into the filename is kept in a simple database. When we finally upgrade to TUGID <don't ask me where these names come from , most of these naming issues will be resolved as tugid will be an inline renamer/database which will allow us to strip a lot of the info out of the filename and into the database.

Also, TOSEC update on saturday night, i will post the relevant Amiga files to a new thread

[Amiga1992]

I know it ain't a simple job, Icy... and I doubt a program could be made so it checks disks completely and could say ' this is a save game, this is garbage', etc...

The work you guys do is really appreciated (despite our whinning )

Looking forward for the next update.

@CodyJarrett:
"it seems silly to use ROM tools like ROMCenter with Amiga disks" -> of course it is silly, but what else should we use? unless someone programs a tool that is able to check & identify ADF files on a file system level the ADF's crc value is the only way we have of recognizing & labelling a certain disk.
"the long filenames of the TOSEC naming system will not work on a real Amiga" -> there is something called TNC (TOSEC Naming Convention, available here ) that we renamers have to stick to. the renaming method you propose provides for short filenames, alright, but as i stated earlier, the whole point of our renaming is to come up with long, descriptive filenames. if you don't like that naming style, don't use the TOSEC dats.

@WindowsKiller:
"If someone save the highscore, the guys from TOSEC have to add this as a "new" version of the game." -> you can save as many highscores as you want to, as long as you keep those 'modified' ADF images for yourself and don't distribute them on the net.

@andreas:
"I think that the TOSEC Amiga set contains many images *not* marked as bad, but being bad, having track errors and all that stuff. " -> given the large number of ADF files in the TOSEC dat, we can't realistically check every single one of them for track errors and stuff like that. what we usually do is we load up the game, check if it is playable in the emus, and if it's not it gets a [b] marker... that doesn't mean it is a bad dump, it might just as well be a emulation problem. if you happen to know for sure that such and such file in our dat is bad, PLEASE message us.

@Akira:
"I might think the image is bad, and delete it." -> LOL. Who said that images that aren't recognized by the TOSEC dat are bad? The dat is still being worked on and far from complete. I'm sure there's plenty of people with lots of unrecognized images - most of them will be added to the dat sooner or later. Patience, dudes!

@IanCharge:
"Evertime we break our highest scores or add a save game file, we'll have to send it to TOSEC, so they can verify and add it to their list." -> Very funny. If you have disks with savegames and stuff like that, don't expect us to include them in the dat. If you want those renamed, you'll have to do it yourself.

[Ian]

Obviously can't take a joke, I thought I made it pretty clear that it was a joke, seems I failed

BTW I do my own renaming, all my multi disk games have their own folders, and the disks are named, well let's see if you can guess ............. Thats right, Disk 1, Disk 2 and so on

@IanCharge:
Hehe... of course i knew you were joking. Just didn't think it was particularly funny

[Codetapper]

OK guys, I will put my 2c worth in here from a programmers point of view:

Identifying disks does seem strange to me as I have them all named correctly anyway. However, if there are a lot of dud cracked versions out there it is nice to be able to identify each disk as the dud without having to check it yourself.

Anyway, an old virus library recognition system called BBBF used a simple but quite elegant way of identifying bootblock viruses, it searched for 4 key longwords in the bootblock that would uniquely identify each virus, by storing only $10 bytes (16 in decimal) it could identify each virus.

If someone was prepared to manually check each disk and include the data, I think it could work pretty well...

Let's say we have a dos game, Line of Fire. No matter what else is on the disk, the database should know the main game file is called "line" and filesize is 123456 bytes, crc is 12345678. The cracked version has same filesize but crc 87654321.

In case there are other games with the file "line" on the disk, it is unlikely to have that exact same filesize. You could always include some other check like game must have both line+credits.iff or something and CRC both files...

If someone is so stupid as to rename the main file, well tough - that person is an idiot. The game won't be identified...

Now for NDOS games, CRC the entire disk image as most people are not capable of changing NDOS games, possibly you could also see where the high scores are saved and skip that track - generally the very final track or the very first one contains the high scores, so maybe CRC the whole disk, + the disk from tracks 2-159 and tracks 0-157?

The other idea would be the specific longwords technique again, check the values at theh start of each track on the disk or something like this, but some corrupt versions might again slip through the cracks...

[Ian]

If you know it was a joke then why did you dignify it with a responce explaining your opinion?

As for the joke I think you did think it was funny.

@IanCharge:
"Evertime we break our highest scores or add a save game file, we'll have to send it to TOSEC, so they can verify and add it to their list." -> Very funny.

Your last to words interest me, you said Very funny, meaning you thought it was funny, no Very funny? Or do you post things you don't mean?

PS. Used the (your?) DAT for renaming Alien Breed Tower Assault downloaded from PE2000, only renamed disk 1 though, none of the others(I had renamed them to Disk 1 and so on and was using clrmamepro).

Anyho' keep up the good work and good luck, however IMO it has little use for me as the end user.

@IanCharge:
"Very funny." -> that was ironical... (you know, irony = saying things you don't mean ). i'm sorry if my post seemed a bit edgy, but i'm sick and tired of having a zillion versions of an ADF file where someone saved a game, a highscore or whatever...

As to the Alien Breed - Tower Assault question, it is possible that the set that can be downloaded from Pe2000 is slightly different from the one in our dat... also, make sure you use the latest version of the dat (available here).

[icycool]

Now now peoples, there is no need to get hostile, mroph has renamed a few thousand images for TOSEC Amiga, and would probably like a little respect for his work. I guess renaming that many things drives u a little to the edge sometimes.
There are probs with TOSEC regarding amiga, but on the whole, we are making progress, which is the main thing.

[Ian]

Right, if I had known that people were actually doing what I was joking about of course I wouldn't have posted "The Joke" and I completly understand why this is a sore subject for you Morph72 ........... NOW

How many different versions are we talking about here 10's 100's or what?

[icycool]

10's max, Its usually the first disk that changes a lot, the other disks in a game may vary, depending on dump quality or even some strange dump software (i came across someone with some overdumped 901120 disks) no idea how they managed that, but it does happen. Also, some things will modify the sector data slightly, even tho this is program/user transparent, it will affect detection. Again, no clue as to what software would do that, or would even want to bother doing that < probaby shoddy or lowlevel coding which is quite unnecessary for unprotected disks, as the trackdisk.device works fine.

[Amiga1992]

Morph, my point about 'having disks that Romcenter might not recognize', was directed toward disks that I use, and might have savestates and such. There's no way those subtleties can be considered in teh TOSEC project, but I Could stil haev a valid image, that it would be recognized by teh TOSEC dat if I didn't saved any game onto it.

Do you get my point? My point is that it doesnt work quite right, but we are stuck with it, since a tool as the one Codetapper theoretically describes, does not exist.

At no point I have said teh TOSEC is good for nothing

[Twistin'Ghost]

|cy[ool
...(i came across someone with some overdumped 901120 disks) no idea how they managed that, but it does happen.

OK, I haven't spread them, I just deleted them when this happened, but I have used software (on the Amiga) that over time creates disk images this size. It's been about a year since I've actually even been on my A2000, so I can't remember the name of the software, but I was creating ADFs from FMS virtual drives (pretty sure it was FMS...it's been a while!)

I would un-DMS to the FMS device and then copy the corresponding image (renamed as an adf). Most of the time this would work, but at some point, the filesize changed, I would have to reboot, delete the fms images, and create them new all over again. This should at least shed some light on how these images happen.

[Twistin'Ghost]

It should also be noted that the TOSEC filenames also croak when burning them to CD...

Not slagging the project, just supporting the need for shorter filenames with less information (that belongs in a database.)

[icycool]

Oki, Last things first :P

The filenames in TOSEC do suck as a lot exceed the joliet 64 char limit (i think its 64 ), and we had a bit of whining from other bulk collectors on the web about it also.
Right now, we are not really concerned with making files comfortable for cd, and infact for 'real' amiga users with the 30 char limit on the Amy filesystem. What we are concerned about is data retention, especially since most of the tosec dats only have information in the filename, and not extra information offloaded into a database.
When we finally get TUGID happening, shouldn't be too long now, we will have a database with an inline renamer, so filenames can be stripped as need be to fit within media/filesystem constraints .

And on with the show;
That program you mentioned Twistin' sounds like absolute crap, especially if it performance degrades over time :laugh

Enclosed here are two versions of one program I wrote many years ago.
What it does is reliably dump out a disk to a harddrive or ramdisk. So anyone using this proggy must remember to have the available resources.
Directions are: From a CLI window >readdisk[0/1] 'path:filename'

Then you will see this 'oOoOoOo...........', each circle represents a read sector, the program will keep rereading sectors it cannot get first time (good for dusty disks) and if all else fails, you can hold down the RMB to skip that sector (remember, this will result in a bad dump of whatever you are trying to copy, so mark it as such)
If a sector read fails 80 times (i think), the program will abort
Also, if you eject the disk while its reading, abort and of course if u run it without a disk in the drive.
Its a very basic program, and was never intended for use by anyone other than me, however as a stopgap for people using crappy programs, i am sending it out.
There are 2 versions of the file, one for df0: > readdisk0 ... and one for df1: > readdisk1
Enjoy

[Twistin'Ghost]

Well, in my case (back then, anyhow) was that all of my source files were in DMS format. I had no intention of un-dms'ing the files to actual disks. For one, it's terribly slow. For another, DMS does not report that it is writing to bad disk sectors, it just does its thing. Both of these issues were resolved by unpacking to a virtual (FMS) disk. Then, after unpacking, the adf is there and you only need to copy it (or in my case, I used DOpus Copy As to the actual game name and disk number.)

For the most part, this was a productive process. It's just that somewhere along the ways, those virtual disks expanded. And I don't understand what caused this to happen. It could be FMS, or some other process that caused them to elongate. As long as you made a point to look at the filesize every time, there was no issue. But when converting literally hundreds of files, the eyes grow weary, the process becomes systematic and a few slip through the cracks.