There is a ladspa plugin doing that and it's made available by ladspa-karaoke element (plugins-good). However, I didn't manage to build a working pipeline using it...

gst-launch --gst-debug-level=2 filesrc location=song.mp3 ! decodebin ! audioconvert ! ladspa-karaoke ! audioconvert ! alsasink

loops with WARN message (no sound produced):

gst-dsp gstsignalprocessor.c:585:gst_signal_processor_pen_buffer: Pad ladspa-karaoke0:Right-in already has penned buffer
0:00:04.664787000  5522 0x8082fa0 WARN   

then stops after a while.

This is due to how LADSPA elements work: They only process one channel per pad.  The karaoke element needs stereo, so you need to split the input channels (deinterleave) and link two pads for input and two pads for output to make use of it.  The (de)interleave elements are not ported to 0.10 yet, however.

I though that was something like that. Pads number for each elements simply does not match.

I tried to surround the filter like this:
... ladspa-split ! ladspa-karaoke ! ladspa-mixer ...
It didn't help either but I guess I'm missing something.

I checked in the audiovoice plugin in -good but I have some other algorithm that mght give better results.

Where can one get the ladspa karaoka plugin btw? Would be nice to get the gstreamer ladspa wrapper working with it ;)

Ok, found it... things are playing at least with

gst-launch-0.10 -v filesrc location=/path/to/file ! decodebin ! audioconvert ! "audio/x-raw-float,channels=2" ! deinterleave name=d  ladspa-karaoke name=k  interleave name=i ! queue ! audioconvert ! alsasink  d. ! queue ! audioconvert ! k.  d. ! queue ! audioconvert ! k.  k. ! queue ! audioconvert ! i. k. ! queue ! audioconvert ! i.

...but at a far too high speed.

Whatever, this looks more like a bug in the gstreamer ladspa plugin... can this bug here be closed now that we have a voice removal element (it was renamed to audiokaraoke btw).

We do have the audiokarakoke plugin in good since quiet a while.