Bembel-B Blog


Preparing MP3s and Cover Art for SanDisk Sansa e200 Portable Audio Player

Last year I purchased a flash based 2 GB DAP SanDisk Sansa e250 to join my good ole 20 GB HDD player Creative Nomad Jukebox Zen Firewire. Sadly the Sansa is quite picky when it comes to ID3 tags.

SanDisk Sansa e200

By experimenting and reading up I found out how to retag my MP3s using Linux (and probably also Windows using Cygwin) so that they all will be fully recognized. I also found a procedure to nicely resize cover scans which can be displayed when playing a corresponding track.


For ID3 tagging I’m using the command line application eyeD3, as it handles ID3v2.4 and – yes – it’s commandline driven. I made an RPM for Fedora Core 5. The original spec file didn’t work because of using the wrong python version. I’ve put my edited spec file and the RPM into my share.

To handle the cover scans I use ImageMagick.


For better performance one should copy the files to be uploaded to your player somewhere on your harddrive.

Copy your MP3s to some working directory and finally cd into it

mkdir -p ~/wrk/mp3new
cd /windows/g/mp3
cp -r _electronic/Aphex\ Twin/Aphex_Twin-...I_Care_Because_You_Do-1995/ /windows/g/mp3
cp -r _metal/Colonel\ Claypool\'s\ Bucket\ of\ Bernie\ Brains\ -\ Big\ Eyeball\ in\ the\ Sky/ /windows/g/mp3
cp -r _metal/Primus/primus-pork_soda-1993/ /windows/g/mp3
cd ~/wrk/mp3new


The Sansa preferres ID3v2 tags over ID3v1 and can read up to ID3v2.3 tags. But it doesn’t seem to like some of the special fields possible with ID3v2.3 and therefore these will have to be removed. The following steps may seem a bit complicated, but it’s the only way to do the cleanup with eyeD3 currently.

1.) Convert to v1.x

find -type f -and  \( -name "*.mp3" -or -name "*.MP3" \) -print0 | xargs -0 eyeD3 --to-v1

2.) Remove v2

find -type f -and  \( -name "*.mp3" -or -name "*.MP3" \) -print0 | xargs -0 eyeD3 --remove-v2

3.) Convert to v2.3

find -type f -and  \( -name "*.mp3" -or -name "*.MP3" \) -print0 | xargs -0 eyeD3 --to-v2.3

4.) Remove v1

find -type f -and  \( -name "*.mp3" -or -name "*.MP3" \) -print0 | xargs -0 eyeD3 --remove-v1

To make things easier, I’ll try to condense all this to one single command next time. So stay tuned..

Cover Art

My procedure will only keep the front cover scans, where available. If you’d like to keep other images too, you’d have to follow the alternative procedure 1b/2b instead of 1a/2a.
Please note: even png images will be renamed to folder.jpg ImageMagick will correctly recognize them as pngs when converting.

If you’d prefer not to use folder.jpg for the resized cover images you may instead use Album Art.jpg as filename.

1a.) List all jpegs and png files. Then manually delete all unneeded files!

find -type f -and \( -name "*.jpg" -or -name "*.JPG" -or -name "*.png" \)

2a.) Rename cover images to folder.jpg

OLDIFS=$IFS ; IFS=$'\n' ; \
for fn in `find -type f -and \( -name "*.jpg" -or -name "*.JPG" -or -name "*.png" \) -not -name "folder.jpg"` ; \
do mv -v "$fn" "${fn/`basename "$fn"`/folder.jpg}" ; \
done ; IFS=$OLDIFS

1b/2b.) Alternative: To keep other images as well, you’d have to manually rename (or copy to keep the original) the front cover images to folder.jpg

3.) Proportionally resize cover images to max 200 x 200 px

OLDIFS=$IFS ; IFS=$'\n' ; \
for fn in `find -type f -name folder.jpg` ; \
do mogrify -verbose -resize '200x200>' "$fn" ; \
done ; IFS=$OLDIFS

I must admit this isn’t the most elegant way. Maybe I’ll manage to make some little GUI and trying to automatically chose the front cover image files. We’ll see..

Uploading to the Player

Nothing special here. Just plug in your Sansa in MSC mode. Then move the files to the player.

mv -v * /media/Sansa\ e250/MUSIC

If you’re replacing files on your player, you’ll have to purge the tag database in order to let the player recognize the changes.

rm /media/Sansa\ e250/SYSTEM/DATA/PP5000.DAT


[070923 Fix backslashes (“\\” markup was meanwhile rendered as “\\” and not “\” as before.]
[080120 Add “Sansa e200” category and link to it.]


Amarok Bluetooth Remote for Sony Ericsson K750i Mobile Phone

A few weeks ago I purchased a shiny new mobile phone, the Sony Ericsson K750i, to replace my good ole Sony Ericsson T610. A nice feature of the K750i are the freely configurable Bluetooth Remotes via BT HID, which are also available on other models.

Sony Ericsson K750i

So I wanted to remote control my favoured music player Amarok. I found a ready made HID configuration by tnt, but unfortunately the keystrokes where not the default Amarok global hotkeys’ ones and also conflict with the default Gnome shortcuts. With the help of Stefan Tomanek’s great website and the HID Usage Tables Reference (page 53) I modified the Remote Control keys to match the Amarok defaults.

A ready to use .hid file is now available from my share.

If I wasn’t lazy right now, I would provide the new HID profile ready to use – an uncompressed tar archive containing the GUI screen as JPEG image and the HID configuration as a UNIX style XML file. But I’ll have to add the GPL stuff first. So for now here’s the diff of the key codes:

[scheff@p512o amarok-hid]$ diff *kcf*
<         <KEYBOARD MODIFIERS = "0A" USAGEID = "56"/> <!-- REWIND -->
>         <KEYBOARD MODIFIERS = "05" USAGEID = "50"/> <!-- REWIND -->
<         <KEYBOARD MODIFIERS = "08" USAGEID = "06"/> <!-- PLAY -->
>         <KEYBOARD MODIFIERS = "05" USAGEID = "4A"/> <!-- PLAY -->
<         <KEYBOARD MODIFIERS = "0A" USAGEID = "57"/> <!-- FAST FORWARD -->
>         <KEYBOARD MODIFIERS = "05" USAGEID = "4F"/> <!-- FAST FORWARD -->
<         <KEYBOARD MODIFIERS = "08" USAGEID = "1D"/> <!-- PREV -->
>         <KEYBOARD MODIFIERS = "05" USAGEID = "4B"/> <!-- PREV -->
<         <KEYBOARD MODIFIERS = "08" USAGEID = "19"/> <!-- STOP -->
>         <KEYBOARD MODIFIERS = "05" USAGEID = "16"/> <!-- STOP -->
<         <KEYBOARD MODIFIERS = "08" USAGEID = "05"/> <!-- NEXT -->
>         <KEYBOARD MODIFIERS = "05" USAGEID = "4E"/> <!-- NEXT -->
<         <KEYBOARD MODIFIERS = "08" USAGEID = "10"/> <!-- MUTE -->
>         <KEYBOARD MODIFIERS = "05" USAGEID = "10"/> <!-- MUTE -->
<         <KEYBOARD MODIFIERS = "08" USAGEID = "57"/> <!-- VOL UP -->
>         <KEYBOARD MODIFIERS = "01" USAGEID = "57"/> <!-- VOL UP -->
<         <KEYBOARD MODIFIERS = "08" USAGEID = "56"/> <!-- VOL DOWN -->
>         <KEYBOARD MODIFIERS = "01" USAGEID = "56"/> <!-- VOL DOWN -->
\ Kein Zeilenumbruch am Dateiende.

To get this running on my Fedora Core 5 box, all I had to do was uploading the HID configuration to my mobile:

obex_push 5 00:11:22:33:44:55 AmaroK.hid

Then on the phone start the remote choosing my FC5 box as target and connect my HID Server with:

hidd --connect 00:11:22:33:44:55

To remove the connection again, use:

hidd --unplug 00:11:22:33:44:55

Don’t know if that’s necessary, but I had paired phone and PC before.

Have fun! And may the power-source be with you! :]


[070429 Fix minor typo. Add download link. Add photo.]


Rebuilding an FC5 Kernel Optimized for AMD Athlon K7

Filed under: Athlon,build,compile,Fedora,Fedora Core,K7,Kernel,rebuild,RPM,rpmbuild — FrankZabbath @ 23:02

Fedora doesn’t ship with an x86 Athlon (K7 series i.e. Athlons up to Athlon XP) optimized Kernel, so I wanted to build one (the standard one w/o xen etc.) myself. I didn’t find any info on the web about this, except that MK7 has to be enabled in the kernel config.

Fedora Core Logo

Phew, MK7! Sounds scaringly like MI5, MI6 or even MKULTRA.. :))

WARNING: I’m not very familiar with compiling Kernels nor with the Kernel RPMs of Fedora. I once did a vanilla Kernel compile from source and some simple rebuilds of Fedora Kernel RPMs. The described procedure seems to be working for me. But be warned!

0.) Setup non-root rpmbuild environment

Don’t build as root! Be sure to have rpmdevtools RPM installed. Then as the user you want to build with, issue fedora-buildrpmtree. This will setup your rpmbuild environment including a directory ~/rpmbuild.

1.) Get original FC5 Kernel source

Download latest Fedora Kernel source RPM. In my case that is kernel-2.6.17-1.2174_FC5.src.rpm.
Extract the RPM with fedora-extract kernel-2.6.17-1.2174_FC5.src.rpm.

2.) Enable Athlon RPM builds

Create a Kernel config file for Athlon K7 architecture. Do this by copying the kernel-*-i686.config to kernel-*-athlon.config (of course with the * replaced by the Kernel version) and changing that copy like shown in the diff below:

[scheff@p512o kernel-2.6.17-1.2174_FC5]$ diff kernel-2.6.17-athlon.config kernel-2.6.17-i686.config
< # CONFIG_M686 is not set
> CONFIG_M686=y
> # CONFIG_MK7 is not set

This defines an architecture K7 instead of i686.

Edit the kernel-2.6.spec file like shown in this diff:

[scheff@p512o kernel-2.6.17-1.2174_FC5]$ diff kernel-2.6.spec kernel-2.6.spec.orig
< %define buildxen 0
> %define buildxen 1
< %define buildkdump 0
> %define buildkdump 1
< %define release %(R="$Revision: 1.2175 $"; RR="${R##: }"; echo ${RR%%?})_FC5
> %define release %(R="$Revision: 1.2174 $"; RR="${R##: }"; echo ${RR%%?})_FC5
< %define all_x86 i586 i686 athlon
> %define all_x86 i586 i686
< %ifarch athlon
< %define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-athlon*.config
< %define image_install_path boot
< %define signmodules 1
< %endif
< ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 athlon
> ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64
< Source77: kernel-%{kversion}-athlon.config

To sum it up, I enabled building for the Athlon architecture by expanding the i686 entries, defined the aforementioned config file, disabled building of kdump and xen Kernels and increased the revision number.
I increased the revision so I wouldn’t have to replace my recent official Kernel and for better distinguishabilty, but this also means that eventually needed kernel module RPMs have to be rebuilt.

3.) Build the RPMs

Create symbolic links in ~/rpmbuild/SOURCES to the diretory’s content of the extracted RPM e.g. like this:

[scheff@p512o kernel-2.6.17-1.2174_FC5]$ ln -s /home/scheff/src/kernel-2.6.17-1.2174_FC5/* /home/scheff/rpmbuild/SOURCES/

Build the binary and and source RPMs with:

[scheff@p512o kernel-2.6.17-1.2174_FC5]$ rpmbuild -ba --target=athlon ~/rpmbuild/SOURCES/kernel-2.6.spec

The building process will take a very long time (for me about an hour or so). But once successfully finished (exit 0) you should find these RPMs:

Now you could delete the symlinks in the ~/rpmbuild/SOURCES diretory, to keep it clean.

4.) Installing the RPMs

Well, if you dared to build the Kernel RPMs you shouldn’t need assistance in intalling them, but just for the sake of completeness:

[root@p512o ~]# rpm -ihv /home/scheff/rpmbuild/RPMS/athlon/kernel-2.6.17-1.2175_FC5.athlon.rpm /home/scheff/rpmbuild/RPMS/athlon/kernel-devel-2.6.17-1.2175_FC5.athlon.rpm

Reboot and check if your homegrown Kernel behaves nicely. For me it did very well and a bit faster me thinks.
And don’t forget that you need to build the matching kernel modules, if the kernel revision number was changed. For me that is kernel-module-ntfs-2.6.17-1.2175_FC5-2.1.27-0.rr.10.5 (see linux-ntfs homepage for build instructions) and kmod-fglrx-8.27.10- (see my previous posting for build instructions) both with Athlon optimizations.


One thing that makes me wonder, is that uname -m still shows i686, but I’m not sure if this is normal.
The kernel config shows 3D Now is enabled and Machine is indeed set to K7.
It would certainly have been better to do a menuconfig with the 2.6.17-1.2174_FC5 config in the kernel source tree. Here’s the config diff:

[scheff@p512o boot]$ diff config-2.6.17-1.2175_FC5 config-2.6.17-1.2174_FC5
< # Linux kernel version: 2.6.17-1.2175_FC5
< # Fri Aug 25 01:03:12 2006
> # Linux kernel version: 2.6.17-1.2174_FC5
> # Tue Aug  8 15:26:05 2006
< # CONFIG_M686 is not set
> CONFIG_M686=y
> # CONFIG_MK7 is not set

If you find any errors or nonsense please comment. Feel free to ask questions, too. This posting is prone to change, as this was my very first and dirty attempt.


[070429 Fix minor typos. Fix some markup. Add logo image.]

Building ATI fglrx Graphics Driver Kernel Module RPMs Based on Livna Releases

For the latest Fedora Core 5 Kernel there were no ATI fglrx drivers available in the Livna repository for many days, so I built them myself. It’s also not advised to use the driver installer provided by ATI, as this will mess up your system. This procedure should also work with the Livna NVidia drivers, I guess.

Fedora Core Logo

The funny thing is, half a day later, the long awaited RPMs were finally available in the Livna repository. But as it wasn’t all too trivial to build these RPMs for rather a beginner like me, here is what I did.

0.) Setup non-root rpmbuild environment

Don’t build as root! Be sure to have rpmdevtools RPM installed. Then as the user you want to build with, issue fedora-buildrpmtree. This will setup your rpmbuild environment including a directory ~/rpmbuild.

1.) Get the latest Livna fglrx binary, devel and source RPMs

Install Livna binaries and devel RPMs:

yum --enablerepo=livna install kmod-fglrx xorg-x11-drv-fglrx-devel

Download the matching source RPM from Livna, e.g.:


2.) Adapt the source RPM to the new kernel release

Extract the source RPM using fedora-extract.

Modify the fglrx-kmod.spec file like shown in this diff:

[scheff@p512o fglrx-kmod-8.27.10-]$ diff fglrx-kmod.spec fglrx-kmod.spec.orig
< %{!?kversion: %define kversion 2.6.17-1.2174_FC5}
> %{!?kversion: %define kversion 2.6.17-1.2157_FC5}
< %ifarch i686 ppc athlon
< #define smpvar smp
> %ifarch i686 ppc
> %define smpvar smp
< %ifarch i686 x86_64 athlon
> %ifarch i686 x86_64
< #define kdumpvar kdump
> %define kdumpvar kdump
< Release:        0.%(echo %{kverrel} | tr - _)
> Release:        2.%(echo %{kverrel} | tr - _)
< ExclusiveArch:  i586 i686 x86_64 athlon
> ExclusiveArch:  i586 i686 x86_64

I changed the kernel version to the desired revision number, lowered the fglrx release number to be able to catch the official build via yum updates and enabled athlon architecture builds. Furthermore I disabled the forced building of kernel modules for smp and kdump kernels. because I don’t use them.

This was the only file, that contained the kernel version as a variable. The other files partly use uname -r, so we will have to build the modules with the corresponding kernel release running.

3.) Build the fglrx kernel module

As mentioned above, one has to be running the kernel release one wants to build for. So if you are running a different kernel now, boot the right one.

Now symlink the sources to your rpmbuild directory:

ln -s /home/scheff/src/fglrx-kmod-8.27.10-* /home/scheff/rpmbuild/SOURCES/

To build the Athlon optimized kernel module binary RPM type:

rpmbuild -bb --target=athlon ~/rpmbuild/SOURCES/fglrx-kmod.spec

Now you could delete the symlinks in the ~/rpmbuild/SOURCES directory, to keep it clean.

That’s it. You now should have the kmod-fglrx-*.rpm in your ~/rpmbuild/RPMS/{arch} directory ready for installation.
If you are updating your running fglrx kernel module, you will have to stop the X server (# init 4), unload the fglrx kernel module (# rmmod fglrx) and then start up your X server again (# init 5).


[070429 Fix minor typos. Fix some markup. Add logo image.]
[060929 Fix minor typo and markup]


The SATAnic Power of State-of-the-Art OSes and Installing Them

I recently did a clean install of Windows XP and Fedora Core 5 on my SATA HDD and it was quite an odyssey to get it working. I’ll briefly describe the odds I was confronted with. The real problem was to get Windows NTLDR/boot.ini bootstrap and the GRUB bootloader installed and configured correctly. One source of trouble seems to be that I had my old (even though unpartitioned) IDE HDD still plugged in and it could not be disabled in the BIOS. I am using an Asus A7N8X-E Deluxe mainboard.

Installing Windows XP

Of course one needed to have the Sil SATA driver on a floppy disk and press F6 when the Windows XP Install CD got booted. I knew this already. But downloading that 20+ MB driver package from the Asus website took over 30 minutes with about 13KB/s.. Very frustrating!
The strange thing with the Windows install was that it wouldn’t let me install on the SATA HDD without having enough free space on the IDE HDD. I had to create some partition on the IDE HDD and then the first step of installation continued.
Funny enough, the Windows bootloader got installed on that IDE HDD. So I had my Windows installed on drive C: (SATA) and the bootloader on drive D: (IDE) with a boot.ini configured to load Windoze from the second (SATA) HDD.
To fix that, I had to change the boot.ini to use the first HDD. I edited the file using a Linux Live-CD and copied it to a floppy disk (as there is no text editor included in the Windows Recovery Console AFAIK). Then I booted the Windows Recovery Console and copied all files from the IDE drive and the fixed boot.ini from the floppy disk to the SATA drive. This of course only was sufficient, as I wanted to use GRUB as my bootloader. Quite interesstingly, the drive letters using the Recovery Console where different, i.e. C: was IDE and D: was SATA.. Stupid drive letters anachronism I say!

Installing Fedora Core 5

The installation process was quite straight forward. Only thing that was annoying: There was only the option to install GRUB into the boot sector of the IDE drive or into the beginning of the first Linux partition (SATA). So I had to reinstall GRUB giving the desired destination after the OS was installed.
But this wasn’t enough. The problem is that I booted from CD and therefore the CD-ROM drive was seen as first boot drive and the HDD was considered the second drive. So I had to edit /boot/grub/ and define the HDD to be the first boot drive and do a reinstall of GRUB (grub-install /dev/sda).


Some part of problems I think were caused because I had that IDE HDD still installed. On the other hand the installer programs should be smart enough to automagically get around these problems. Sadly I didn’t find the solution as directly as it may sound. Searching the web I didn’t find anything describing my case, so this is why I wrote this..
My description of problems and how I solved them is surely very compressed for such a complex and confusing topic. So feel free to ask for clarification etc. by commenting.


[2006-04-23: Add tags.]


How to clone a defective hard drive, migrate a Linux installation, and locate defective files

As my (just 15 months old Samsung IDE) hdd continuously had more and more bad sectors, I had to replace it with a new (Seagate SATA) one. Here’s what I did to save as much data as possible, keeping my old filesystems (NTFS, FAT32, ext3, swap).

old opened hard disk drive


Boot from the Linux Live-CD Knoppix 4.0.2 enabling DMA at the boot prompt with knoppix dma.

cat /proc/swaps shows me Knoppix is using the swap partition on my defective hdd.

All following commands in this entire HOWTO have to be issued as user root! Use su - to switch to root.

So I unmount the swap partition with swapoff /dev/hda6.

Now the cloning process using dd_rescue is started, filling unreadable sectors with zeroes.

dd_rescue -A /dev/hda /dev/sda

About two hours later copying of all 160GB is finished.
As I didn’t set a logfile for dd_rescue to report bad sectors and Knoppix’ dmesg has only a small buffer space (and the syslog file isn’t used at all), I sadly ain’t able to name all the bad sectors positions at this time. So you would better use that logfile option!
So for now I only know the number of bad blocks (1328!), the total amount of unreadable data (~700kB), and, from what I could read scrolling down the terminal screen, the approximate locations of the bad blocks given in MB counted from the beginning of the hdd.

Let the cloned Linux installation use the new hdd

As I wasn’t able to mount the cloned partitions immediately afterwards, I did a reboot of Knoppix and it worked then. Good thing!

mount -o remount,rw /dev/sda2
mount -o remount,rw /dev/sda3

I now have to fix the partitions locations definitions for my cloned Linux installation to use the new hard drive.

I add the line (hd1) /dev/sda to my boot partition at /mnt/sda2/grub/

Also change the grub bootloader configuration at /mnt/sda2/grub/grub.conf from hd0 to hd1 and the kernel parameter root like this:

title Fedora Core (2.6.12-1.1372_FC3)
        root (hd1,1)
        kernel /vmlinuz-2.6.12-1.1372_FC3 ro root=/dev/sda3 rhgb quiet
        initrd /initrd-2.6.12-1.1372_FC3.img

Then there’s to fix the fstab at /mnt/sda3/etc/fstab. I change the device from /dev/hda to /dev/sda and also switch from using labels (/boot and /) for my Linux partitions to using the distinct device node names (/dev/sda2 and /dev/sda3).

Also mtab at /mnt/sda3/etc/mtab has to be fixed the same way.

And as I am using automount, these configuration files (/mnt/sda3/etc/auto.*) have to be fixed too.

Only thing left is the swap partition. I fixed that simply by rebooting from the new hdd (as defined in the BIOS settings) and typing this in the terminal:

swapon /dev/sda6
swapoff /dev/hda6

UPDATE: The above configuration still uses the bootloader in the old HDD’s MBR. The old HDD is still seen as the first boot device by the BIOS (therefore I use hd1 and not hd0). I figured that out when I wiped my old HHD’s partitions.
To exclusively boot from the new (cloned) HDD, you have to reinstall GRUB on this HDD. The process I would have had to use is a little tricky, and can be found in my posting about installing OSes on a SATA HDD.
In brief, one boots from the Fedora Rescue CD and chroots to the Fedora partition on the new HDD. Then fix the /boot/grub/ to see the HDD as first boot device and reinstall grub on this HDD. You would also have to fix /boot/grub/grub.conf to use hd0 instead of hd1 and configure your BIOS to boot from this HDD.
If you still have your old HDD intact (i.e. the system is booting from HDD), you most probably can skip the step of booting from the Rescue CD and simply boot from the HDD.

Let the cloned Windows XP installation use the new hdd

Heheh.. No way, dude! At least it would take hours and days from my knowledge. You would have to edit \boot.ini and also the System Registry’s drive and partition definitions. And then all paths and drive letters still point to the old hdd (as far it’s still plugged in).
So, once again, Microsith’s ultimate answer is: Reformat and reinstall! Outch!

Find bad sectors and affected files

The SMART system will only name the first bad sector it finds. On Linux there’s a tool called badblocks. I only tried its non-desctructive read-write test and it’s slow but reliable. But if you kept the dd_rescue log (unlike me), you find the block numbers there.

To locate a file by block number on a Linux filesystem (ext2, ext3, minix, reiserfs etc.), one can use debugfs as described in a HOWTO at smartmontools.

Locating files by sector or block number on a NTFS partition is possible under Linux with the use of ntfscluster found in the ntfsprogs utility suite by the Linux-NTFS Project.

How to do this on FAT or NTFS systems is still unknown to me. After googling for quite a long time I still did not come up with a solution. I guess one should be able to accomplish this with a disk editor. Still the question, which one would that be?!

Copyright notice

The photograph showing an old opened hard disk drive used in this entry is in the Public Domain and thus free of any Copyright restrictions. The content is provided by Michael Connors and Morguefile and has the ref id# 13218.


[2006-04-23: Add tags.]
[2006-07-21: Reinstall GRUB to be able to boot exclusively from the clone. Locate files by sector or cluster number on NTFS partitions. More tags.]

Create a free website or blog at