File name problem(?)

All four of /dev/fd/0, /dev/stdin, /proc/self/fd/0 and /dev/pts/2 are file names, as are /////dev/../dev/fd//0, /bin/sh, /etc/fstab, /fioejfoeijf, etc. All but that last example are likely to be the name of an existing file on your machine. A file name is a string that can designate a file on your filesystem; under Linux, any string that does not contain a null byte and that is at most 4096 bytes long is a valid file name. Many of these names are equivalent, e.g. /bin/sh is equivalent to ///bin/sh, /bin/../bin/sh (assuming /bin is an existing directory), etc. All the examples I've given so far are absolute file names; there are also relative file names, which do not begin with a / and whose meaning depends on the current directory.

The terminology surrounding file names isn't universal; sometimes “file name” means a full path to a file, and sometimes it means the name of a directory entry. The POSIX terminology is “filename” or “pathname component” for the name of a directory entry, and “pathname” for a full path.

A file descriptor designates an open file in a particular process. The kernel maintains a table of file descriptors for each process. Each entry in the file descriptor table indicates what to do if the process requests reading, writing and other operations on the file descriptor.

File descriptors may correspond to a file and have an associated name, but not all of them do. For those that do, the file may be a regular file, a directory, a device file or a named pipe (also called FIFO) (the kind created by mkfifo); some systems have further possibilities such as Unix sockets and doors. Examples of file descriptors that don't have an associated named file include pipes (the kind created by the pipe system call) and networking sockets.

/dev/fd/0, /dev/stdin and /proc/self/fd/0 are file names (all equivalent) with a peculiar meaning: they all designate whichever file is currently accessed via file descriptor 0. When a process opens these, the kernel copies the entry with index 0 in the file descriptor table to a new descriptor. Opening any of these files is equivalent to calling dup(0). The named files are a way to indirectly get a process to use one of its already-open files rather than open a new file; they are mostly useful to pass on a program's command line, where the program expects the name of a file to open.

As other answers have already identified, ${f%.*} is expanded by the shell before it runs the xargs command. You need this expansion to happen once for each file name, with the shell variable f set to the file name (passing -I f doesn't do that: xargs has no notion of shell variable, it looks for the string f in the command, so if you'd used e.g. xargs -I e echo … it would have executed commands like ./somedir/somefile.wmacho .mp3).

Keeping on this approach, tell xargs to invoke a shell that can perform the expansion. Better, tell find — xargs is a largely obsolete tool and is hard to use correctly, as modern versions of find have a construct that does the same job (and more) with fewer plumbing difficulties. Instead of find … -print0 | xargs -0 command …, run find … -exec command … {} +.

find . -name '*.wma' -type f -exec sh -c 'for f; do echo "${f%.*}.mp3"; done' _ {} +

The argument _ is $0 in the shell; the file names are passed as the positional arguments which for f; do … loops over. A simpler version of this command executes a separate shell for each file, which is equivalent but slightly slower:

find . -name '*.wma' -type f -exec sh -c 'echo "${0%.*}.mp3"' {} \;

You don't actually need to use find here, assuming you're running a reasonably recent shell (ksh93, bash ≥4.0, or zsh). In bash, put shopt -s globstar in your .bashrc to activate the **/ glob pattern to recurse in subdirectories (in ksh, that's set -o globstar). Then you can run

for f in **/*.wma; do
  echo "${f%.*}.mp3"
done

(If you have directories called *.wma, add [ -f "$f" ] || continue at the beginning of the loop.)