In the Wikipedia article on Transmeta there's a good example for the Code Morphing process, taken from a PDF document (Wayback archived) with even more details:
The operation of Transmeta's code morphing software is similar to the final optimization pass of a conventional compiler. Considering a fragment of 32-bit x86 code:
add eax,dword ptr [esp] // load data from stack, add to eax
add ebx,dword ptr [esp] // ditto, for ebx
mov esi,[ebp] // load esi from memory
sub ecx,5 // subtract 5 from ecx register
This is first converted simplistically into native instructions:
ld %r30,[%esp] // load from stack, into temporary
add.c %eax,%eax,%r30 // add to %eax, set condition codes.
The optimizer then eliminates common sub-expressions and unnecessary condition code operations and, potentially, applies other optimizations such as loop unrolling:
ld %r30,[%esp] // load from stack only once
add %ebx,%ebx,%r30 // reuse data loaded earlier
sub.c %ecx,%ecx,5 // only this last condition code needed
Finally, the optimizer groups individual instructions ("atoms") into long instruction words ("molecules") for the underlying hardware:
ld %r30,[%esp]; sub.c %ecx,%ecx,5
ld %esi,[%ebp]; add %eax,%eax,%r30; add %ebx,%ebx,%r30
These two VLIW molecules could potentially execute in fewer cycles than the original instructions could on an x86 processor.
So it indeed translates the x86 binary code into the native VLIW binary code. You can call this "binary translation", and it's not an "interpreter", and it's not a "virtual machine" (though this notion is a bit fuzzy; a virtual machine can use various methods to execute actual code, including translating it).
Also note that modern x86 CPUs all use a similar scheme: They translate x86 binary into a more simple, RISC-like code, and then schedule and execute it.