You can very easily prove the offset issue, and give you a good idea how much metadata it carves out. Look at the HDD specs online, get total number of blocks & bytes. Then look at the O/S and see how many bytes it says the HDD is. Also the make/model of the HDD that device manager says you have. If it isn't the same make & model then you have proof.
I write storage diags and RAID management software for a living, so this is pretty old-hat to me, so apologize in advance for not giving you full instructions to shift it over, but dd is all you need. Just use the start= and count= options to specify exact values, and I would make block size is at least 64kb (bs=64k is parameter). If total number of blocks is not a multiple of 64kb then you need to do a 2nd dd starting near the end of the drive using the (start= and count=) parameters, and do not specify block size. This will copy one block at a time.
That way you can still copy large chunks of data at once and not worry about clipping the tail end of the disk. Then you can use a partition manager to incorporate the last few MB or KB left free at the end of the disk by the metadata if you want to get 100% of the disk usable.
Don't be tempted to do this in-place (it is possible with a c program using memcopy as this will prevent source and destination pointers from walking over each other during the copy). Best practice is also to do a media verify on source (simple dd if=/dev/sda (or whatever) of=/dev/null bs=64k). This will let you know if you have any read errors as it just reads entire disk into bit bucket. If you have a read error, then you won't be able to use dd until you repair the bad block.
