I did try without compression using gzip, i still get the same results. Also I did try without the conv= and no difference.

Any other ideas?

The only other idea I have is to try different 64M and 128M disks; if possible to grab some new ones which have never been used, perhaps try to get them from the same manufacturer. All I can see from the perspective of linux commands is that you're doing it all correctly. Mine's pretty old, 2009 version 7.4, but then again hard to believe they're developing much on dd these days.

I don't think it should make a difference but did you try adding bs=64K since that is what you did when creating the image. I had posted what I did earlier because not to long ago I was playing around with dd and restoring to different size partitions and notice that the data tend to take up more space when restoring to a partition that was larger than then the original. I don't remember if I was using dd to copying from one partition to another or creating an image with dd and restoring the image to larger partition. It was something I notice and thought that was kind odd at the time.

Since you have noted CE, you might have to use MS tools. It could create some file and reference to some thing that is now different.

maybe gparted-live usb can clue us into what is going on here ?

Unfortunately I do not have the flexibility of getting new drives for this particular hardware. The hardware is pretty old -> Micros DT 166, using a 64MB or 128MB u-dock drive (flash). But if there were an issue with the drives, I wouldn't be able to image a 64 to a 64 or a 128 to 128, which I can do without an issue. Only issue is imaging 64 to a 128.

The version of dd I'm using is 8.4

Yes I did already try adding bs=64k, no luck!

I'd actually do the opposite, which I think you've done, "no argument" therefore dd assumes bs=1 and it takes longer.

You may want to consider little_wolf's suggestion. Which is to use fdisk to determine the partition types and sizes, also file system types and then manually create a mimic of the drive onto your 128 sized target, and then manually copy contents of each partition. I do that for a raspberry pi based product we have, the boot partition is like FAT32 with the boot flag set and there are like 4 or 5 files which are just copied over, and the second partition is Linux where there's a ext2 file system and so I copy the RFS over to that and that's how I reproduce boot disks for those systems. Actually I do this for several system types and I like it better than dd because over the year's I've found that not all 8G disks are the same and if I copy my image from an 8G disk which has slightly higher than normal usable blocks, then I'm in trouble when I try to dd it over to other blank disks, you run out of space. I didn't want to take a chance at picking some count= value slightly less than 8G and end up missing one tiny piece of data, so the strategy was to create a script which makes the boot partition, the RFS partition, creates the file systems, and then copies files into each of those partitions.

this is what i do:i imaged my 4 gb sd card like so and when it flaked out i replaced it with a 32 gb card and all i had to do after re-imaging was use gparted to extend the boundery of the partition (xbmc boots up just fine... until this sd card bytes the dust <@).

A couple of fairly unlikely things come to mind.

On an old Lenovo laptop I had, the "Factory Recovery" partition (may it rest in pieces) wouldn't work unless it was physically at the end of the disk. You might make a wild stab and copy the last partition to the end of the 128M disk and adjust (or not) the partition table accordingly. It probably won't work, but neither has anything else so far.

You could try using "hdparm -N" to set the max visible sectors to match the smaller drive. (The liklihood of a 128M drive supporting that is probably quite small.)