The DF Lab

So I had a bit of difficulty with this one, and a difficulty that I really only got because I chose to test my files with mplayer. I essentially tried to use the widely suggested method of using cat to combine mp3 files like so:

$ cat a.mp3 b.mp3 c.mp3 > d.mp3

Believe it or not, it works. Apparently the mp3 file format is such that you can do this. However, if you have id3 tags on any of the files, this will cause some issues for playback with finicky audio players like mplayer. While some players (ffplay for example) will ignore such garbage it finds in files, mplayer won’t do it so gracefully. In order to fix this, you have to strip all id3 tags from the files first. After a bit of searching, I found a nice utility which can do just that, aptly named id3v2. All you have to do is use it like so:

$ id3v2 -D a.mp3

And voila! id3 v1 and v2 tags are removed from the file. Simple and easy.

You can pick id3v2 up on sourceforge, but if you’re using Gentoo, there’s an ebuild in the portage tree.

linux cli, music

I can sum up most of my computer-related decisions over the last 3 years or so as all being related to dealing with my hardware as best as possible. This first led me to ditch Windows XP and try out Linux (Ubuntu first). Then I tried fluxbox because GNOME was too heavy. Then I decided that Ubuntu didn’t deal all too well with switching out your desktop environment for a window manager, so I naively tried out this distribution I’ve come to know and love called Gentoo. Now that I’m with Gentoo/fluxbox combo, I’ve managed, over time, to slim down my machine to just what I want, and have a pretty lean box, IMHO. Not the leanest, but I did want a functional and pretty box as well.

Anyway, this all correlates to a recent issue I’ve had with my music accounting system, and how I got around it with some frenzied bash scripting. Because I’ve got a 4GB iPod Nano, I eventually came into the position of having too much music to fit on the device. So I looked at my music and thought about compression. Unfortunately, I couldn’t glean nearly enough space from that. Then I realized that I have way more music than I actually listen to, so why not keep some music for computer listening, and some for mobile? Well that’s a fantastic idea, but implementation gets a bit sticky. I can try some convoluted system in which I keep a file of the unwanted files, update that manually, and… yeah, not too pretty. Although I can’t quite say my solution was much prettier.

My current system involves a ~/music directory, and a ~/music-all directory. My intention is to delete nothing from ~/music-all, ever. ~/music contains music I actually want to listen to, and ~/music-ipod will contain music that I like enough to carry in my 4GB of space. The key is that all the files within these three directories are hard links, so I’m not actually increasing my disk usage very much, and operations on the sets of files are much faster than if I had more than one copy of my files. So assuming I hard link everything in ~/music-all to ~/music, I can then delete things from music at will, without losing it from my drive, but getting rid of it from listening.

With a schema in mind, then there’s the question of how to keep it up to date. There are times when I want to add music to my collection, but then what do I do? I could manually link the new files over, but… well, in retrospect, perhaps that would have been simpler. But I decided I needed a script which would note the differences, relink ~/music-all to ~/music, then remove the files that I noted earlier (which were saved in a text file). The benefit of all my toil was that it now makes my updates lightning fast and not tedious in the least. I had to come up with two scripts, however: one to be run prior to changes to ~/music-all, and one once they’re made. Below are the scripts, which probably won’t be of much use to anyone else, but they can essentially be used to keep two directories in sync, but with certain persistent changes.

mtree-1
mtree-2

Wow, I just spent way too much time figuring out how to post code here, and I’m still not satisfied with the result, so I ditched it. The built-in <code> tag doesn’t seem to take to multiple lines all that well… If anyone knows how to do that, do let me know!

linux bash, linux, music

Honest to God, I spent so much time getting this blog, domain, etc. up, that I almost forgot what spurred me to get started. So here’s why… I had this problem. Rather, not so much a problem as a desire to rotate my backgrounds periodically. Let’s say… every 2 hours. Now, a guy like me, I think “cron!” This is the first thought of any veteran Linux user. However, I quickly came to the realization that I didn’t know quite how or where to put my cron entries, nor what format. This problem was, however, quickly remedied. That was not my problem.

The true problem arose when I attempted to actually implement changing my background. With fluxbox, this should be possible with a simple command like so:

fbsetbg -a -r /home/dfego/.fluxbox/backgrounds/

Simple enough, right? Well, as simple as it was, it just didn’t quite work. So I changed my cron timings, in case I got that wrong then used absolute paths, once again, just in case. Freaked out for a while, because the command itself works just fine. I ran it from a terminal about 29,834 times to make sure, but still, that little cron daemon that could just wouldn’t budge. It would, however, write the text “working” into ~/cronf*cker every minute. As a matter of fact, it still is. Allow me to go take care of that…

Now that that’s taken care of, I’ll go ahead and tell you what the real problem was. Apparently the cron daemon doesn’t have any inherent knowledge of the X display server I want to set the background of. Fair enough, since it starts running well before X gets started. But I didn’t realize this would matter, or even think about it at all until I saw a post online about setting fluxbox backgrounds in a more general sense. It proposed butting DISPLAY=:0.0 before the line, like so:

DISPLAY=:0.0 fbsetbg -a -r /home/dfego/.fluxbox/backgrounds/

I changed the file, bit my lip, and a second or so after the next minute passed, my background was changed anew! As a note, my X server is not using display :0.0, but rather :1.0. You can find out what your value is by opening up a terminal and typing:

echo $DISPLAY

Anyway, there you have it. My first pearl of wisdom to the world! Apologies for verbosity, but sometimes in explanations such as this, it helps. So the moral of the story/digest version: be aware of context when running commands for X! Or something like that. I actually was at work today trying to impress a co-worker of mine with the power of the command line, but unfortunately my attempt fell flat on its face when passing commands to xmessage. I’m not too worried about it though. My ping/grep antics seemed to be enough to win him over.

With that, I’m off to bed, and to watch my background change once more before daybreak!

linux bash, cron, fluxbox, gentoo, linux