[diggrd]

IFO Files give the player important navigational information, like where a chapter starts, where a certain audio or subtitle stream is located, etc. This is the reason why it's only possible to rip certain parts of a movie (like a chapter) with a ripper which can read this files.

BUP files are just backup files off the IFOs. As their counterparts they are not encrypted.

http://www.doom9.org/index.html?/dvd-structure.htm

Wholefile md5 Checksums
Note: Wholefile md5 checksums are the type generated by programs such as mdsum, mkwact, and others. Please read on to understand why these are forbidden as the primary form of file verificaton at The Traders' Den.
The most rudimentary form of md5 fingerprinting is to run the algorithm on an entire file. By comparing two md5 checksum values, one will be able to confirm that the files that generated the values are the same. In the early days of lossless file trading on the internet, this was used to track recordings encoded to the Shorten (.shn) file format. This very effective method of ensuring that all files remain identical from user to user is still popular today. However, there are some fundamental weaknesses to this method, many that have arisen with the advent of .flac and .ape lossless audio formats as the preferred trading format of many users. Both of these newer formats permit the use of file tags so that a user can add artist, date, venue, source, or any other information they want to the file's header for display in their preferred media player. While adding or removing these tags doesn't change the audio at all, it does alter the file to include the additional header data, and therefore changes the file's checksum. Two files would thus appear different in a checksum comparison while being acoustically identical.

Furthermore, there is certain additional data that can be stored in .wav files that .shn and .ape allow to remain during compression, but which .flac sees as unecessary and potentially harmful to your system and thus removes it. Again, it would be possible to convert from .shn to .flac and back and have two acoustically identical files result in different wholefile md5 checksum values.

Yet another weakness to relying on wholefile md5 checksums is the need to use seek tables in .shn files. The earliest version of Shorten's codec did not allow for the files to be seekable during playback. As a "band-aid" for this oversight, they allowed for the addition of a seek table that would be appended to the file to provide the necessary information to make the file seekable. The problem, again, is that by adding this information a user changed the file but not the audio. This problem has been further compounded by the recent addition of alternate versions of seek tables, so that even files with seek tables can contain one of a few versions and thus have differing md5 checksum results while being musically identical.

Wholefile md5 is an effective method of comparing files, but has been made somewhat obsolete by the more versatile methods of audio file verification I'll discuss next.

http://www.thetradersden.org/forums/faq.php?