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

Documenting the [[glossary:copy protection|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 [[glossary:custom disk format|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 [[glossary:IPF]] library does not generate the [[glossary: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 [[glossary:cta|analyser]] without any additional scripting or format information. Things such as [[glossary:track]] length, track [[glossary:gap]] length, [[glossary:block]] order (if there is more than one block per track), inter-block gap size, [[glossary: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 [[glossary:trace machine|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 [[glossary:IPF]] 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 [[glossary: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.