Today, a good friend reported something like a bug in MPlayer’s LAME encoder filter. He said that mpgtx, a MPEG audio/video cut and merge program, pretended that the resulting MP3 files are invalid. Some quick investigation revealed that the files indeed started with a chunk of zero bytes, not with a correct MP3 frame. This doesn’t happen with files produced by the standard command-line LAME frontend, so the problem had to be on my side. Read more …

For quite some time now, I always wanted to record songs from my favourite radio station. However, there was a problem: They only offer a RealMedia stream (at only 44 kbps, but the codec is remarkably good, on par with WMA or Vorbis), which is not as easily recordable as, say, HTTP streaming. However, with the help of the original binary codecs, MPlayer is able to play the stream – so it had to be possible to record it. Unfortunately, MPlayer’s –dump options only record the compressed stream, and MEncoder refuses to transcode it into something usable (.wav, .mp3, …) because it always expects a video stream to be present. Furthermore, none of the dump or transcode options are able to play the stream while recording.

This had to change. And since I had a MPlayer-for-Win32 build environment on my box anyway, this was the right time. After some reasoning, I came up with a functional solution that doesn’t require twiddling around in MPlayer’s innards too much: an audio filter. If –af lame is put into MPlayer’s audio filter chain, it simply encodes all audio samples that pass by into an MP3 file on disk. MPlayer’s audio output is still active, thus an MP3-encoded audio dump is created on-the-fly during playback.
Read more …