Do you plan to add small descriptions for releases explaining the copy protection and disk format?

Documenting the copy protections used on games was considered at one time, but the idea was dropped. There are too many reasons against it.

• There does not appear to be enough interest to warrant it.

• The information is not really useful for anyone but those who are interested in trying to copy a game and could otherwise quite possibly cause confusion and/or spur mails regarding disk formats that we do not have the resources to answer.

• We do not want to start endless “how do I copy game X” threads on message boards.

• Some protection techniques may have applied patents (some theories are certainly still used on other types of media), hence disclosing such information could lead to legal trouble. Apart from allowing authentic reproduction, this is why the IPF (Interchangeable Preservation Format) library does not generate the Copylock data even though we could - in fact the whole track could be stored in 24 bits.

• There are disk properties that are understood and automatically preserved by the analyser without any additional scripting or format information. Things such as Track length, track Gap length, Block (aka Sector) order (if there is more than one block per track), inter-block gap size, Bit Shifting, etc. Basically the “track geometry”. Since the analyser understands any tricks regarding these automagically, this information is not supplied in any of the scripts, nor is it present on IPF files as stored data, it is “mastered” on the fly, just like how the duplicator machine (one from Trace usually) would have done it.

• There are games that seem unprotected but would never work from a copy since the game checks one or more track geometry properties as part of the protection. We do not care about such games, since they work as an IPF (Interchangeable Preservation Format) and would work when rewritten too. They just cannot be copied... These games look unprotected and sometimes even have decoys to fool copiers into thinking that e.g. a Long Track is the protection. This is why the track geometry is preserved. If it ever get used by a program, that program will find what it expects. We are not really bothered to find out exactly what is in it, and how it is used for the thousands of games, especially since the checks may not happen until much later in the game.

• It is quite often that games are written on long tracks, but this is not actually checked by the game code. The reason for this is that most developers did not normally have access to duplication equipment. The script for the game format was changed by the duplicator service to be on longtracks, to cause most copy programs to fail without extra hardware. So e.g. knowing is a game is written on longtracks is quite irrelevant information in reality.

• However, the last point is not the case for tracks that were meant to be protection tracks in the first place (i.e. not data tracks), key disks were supplied by the duplicator service / protection author for developers and were already pre-mastered with the correct data. This is the reason why commercial/generic protection schemes quite often reside on the same disk position, like track 0.1.

Lastly, the analyser finds similarities in track formats, and hence evolutions of or the same formats can be spotted. If we said that game X uses Y format, we are sure that we would get flame/lame mails/posts saying that it is not true because they use completely different loaders etc. As you probably guessed by now, it does not matter what the loaders are, or what they do, it is the underlying disk format that matters. We can see the track data and format and not just the game code, so we can easily tell.