Getting mplayer status from a bash script
Have you ever wanted to query mplayer for playback information? How does one go about querying mplayer for things like the time elapsed, pause state, volume level, mute state and more? If you just want my script sans-details of how it came about, click here.
I'm currently working on a project that is basically a modern-day version of those old read-along audiobooks, the kind where you listen to a cassette/CD while you look at the book, turning the page whenever you hear a chime. When (if) I get it all put together, it will get its own dedicated post, but for now, let me just describe my mplayer dilemma and fix.
I decided pretty early on that I did not want to hard-code the chime sound for page turns into the audio files. There are two reasons for this. First of all, I want to be able to change out the chime sound, and second, I want to be able to control the volume of the chime sound independently from the audiobook so that chimes can be completely muted if desired. This means that the audiobook and the chimes must run in separate mplayer instances.
To accomplish this, I utilize three files:
If you run mplayer from the command line, you see that timing information is displayed on the screen. I figured, "Great, that means I can just pipe the output!" I tried that and had all kinds of problems. When I tried extracting the times from the output I got all kinds of unexpected results. It should have occurred to me sooner what was going on. I only discovered it when I tried to pipe output from my mplayer dump into grep. The grep program complained about the length of the information. As far as I could tell, I was passing a single line! I figured I'd take a look at the file with a hex editor. As soon as I did that it became apparently clear to me what was causing all of my complications. The status that mplayer dumps to the command line doesn't create new lines for each update. When the information is updated mplayer moves the cursor back to the beginning of the line and overwrites the previously outputted status. Duh, that's visually evident if you watch mplayer write its status updates.
Armed with this knowledge, I started by converting everything to hex, fixing the troublesome bytes by replacing the "carriage return" effect with a new line (sed could not handle the binary replacement). With that problem solved, the issue of extracting information about the current playback status became a simple task. Later, I discovered from a StackOverflow post that I didn't even have to convert everything to hex first.
The fruit of my labor is a bash script that can query for useful information about playback status. You'll find it on my GitHub along with usage instructions.
I'm currently working on a project that is basically a modern-day version of those old read-along audiobooks, the kind where you listen to a cassette/CD while you look at the book, turning the page whenever you hear a chime. When (if) I get it all put together, it will get its own dedicated post, but for now, let me just describe my mplayer dilemma and fix.
I decided pretty early on that I did not want to hard-code the chime sound for page turns into the audio files. There are two reasons for this. First of all, I want to be able to change out the chime sound, and second, I want to be able to control the volume of the chime sound independently from the audiobook so that chimes can be completely muted if desired. This means that the audiobook and the chimes must run in separate mplayer instances.
To accomplish this, I utilize three files:
- The audiobook file
- The chime audio file
- A text-based file that lists chime timings
If you run mplayer from the command line, you see that timing information is displayed on the screen. I figured, "Great, that means I can just pipe the output!" I tried that and had all kinds of problems. When I tried extracting the times from the output I got all kinds of unexpected results. It should have occurred to me sooner what was going on. I only discovered it when I tried to pipe output from my mplayer dump into grep. The grep program complained about the length of the information. As far as I could tell, I was passing a single line! I figured I'd take a look at the file with a hex editor. As soon as I did that it became apparently clear to me what was causing all of my complications. The status that mplayer dumps to the command line doesn't create new lines for each update. When the information is updated mplayer moves the cursor back to the beginning of the line and overwrites the previously outputted status. Duh, that's visually evident if you watch mplayer write its status updates.
Armed with this knowledge, I started by converting everything to hex, fixing the troublesome bytes by replacing the "carriage return" effect with a new line (sed could not handle the binary replacement). With that problem solved, the issue of extracting information about the current playback status became a simple task. Later, I discovered from a StackOverflow post that I didn't even have to convert everything to hex first.
The fruit of my labor is a bash script that can query for useful information about playback status. You'll find it on my GitHub along with usage instructions.
Comments
Post a Comment