I've made a little simple diagram to help your case Conqueror.
This is a small top-down snapshot of a frame within a demo recording. The blue line is what you see on your screen, and the red line could be a possible view that is seen by a spectator or in a demo. In essence, the difference between what you're aiming at and what the demo records can become very large at long game distances.
The reason for this inaccuracy can be tied down somewhere inside client -> server -> client transferring of data, client interpolation, and various other networking factors that are complicated to explain.
Generally your client is always interpolating on data from the server in order to move the player in the direction that is expects the player to move from the previous frame. The reason for this interpolation is so that any shots you make actually register when a ray trace is performed and your bullet hits their hitbox.
If interpolation wasn't around, you'd have to lead your target in order for the latency delay between when you fired and when the server received the information that you fired to be accurate to where the player has moved.
This whole complex networked system leads to the inconsistencies when recording demos and spectating players. The effect of missed shots will appear in both demos and when spectating players.
To sum it up: The networking delay between your client, the server, and then the client of the recording player, in addition to the interpolation done by both clients and managed on the server causes the demo to be inaccurate.
You can get alot more information about what I'm talking about at the following places:
http://developer.valvesoftware.com/wiki/QAngle - This value is generally retrieved by calling a function on a player in the engine.
const QAngle &CBasePlayer::EyeAngles( ) to be more exact.
Demo information can be viewed here:
http://svn.bgmod.com/code/trunk/public/demofile/demoformat.h
If you don't read C/C++ code all that well (which I figure you should, since you're going for Comp Sci!

), the format is generally just a big chunk of frames that get recorded. These frames can be the input from your keyboard, voice chat from other players, and basically everything else.
Networking information can be received from here:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking - This describes in general the relationship between the client and the server and how data is sent between them. It goes into short detail about interpolation and prediction.
http://developer.valvesoftware.com/...rver_In-game_Protocol_Design_and_Optimization - This article was written by Yahn Bernier, the chief engineer behind source's networking code. This article will go into a whole lot of detail as to the design behind interpolation and why it's necessary.
I hope this all helps you out!
