Good guess. I probably should have mentioned that. Normally NEC1 is far more common than NECx1 or NECx2, but when the two halves of the System Code are the same, the NECx protocols are more common. I was hoping to determine which NEC protocol it was by examining a learned signal. But the learned signal you posted isn't any NEC protocol.

BTW, A0 hex is 160 decimal, which is where we got 160.160 (For two part device numbers, MakeHex requires you to seperate them with a dot).

When NECx1 is correct then NEC1 or NEC2 might work but unreliably, which might be the behavior you found.

NECx2 is even closer to NECx1. For very short presses of a button NECx2 and NECx1 may send the identical signal. So even though NECx1 seems to work, NECx2 might be correct. The difference would show up in a long press of certain buttons.

I'm not clear on what all the buttons do. The CD doesn't have its own vol commands? The vol is controlled only by a seperate preamp? (normally a long press of Vol+ or VOL- is the best place to test whether NECx1 or NECx2 is better). What about << and >>? Do they have interesting long press behavior with the original remote? If so you could test those with NECx1 vs. NECx2 to see which duplicates the long press behavior of the original remote.

If no button has interesting long press behavior then NECx1 will work perfectly whether it is correct or NECx2 is correct (so there would be no need to find out which is correct).