Mister Muffin Blog

So I was copying files on a vfat-formatted usb stick when this error popped up:

Invalid or incomplete multibyte or wide character

Same issue with cp, rsync and tar. So I just thought this would be an issue with stupid vfat so I mkfs.ntfs the drive and tried again - same issue.

So while I thought that at least NTFS would allow any character except NULL I was proven wrong. Looking it up in wikipedia indeed yielded that ntfs file names are limited to UTF-16 code points - in contrast to ext2/3/4, reiserfs, Btrfs, XFS and surely even more which allow any byte except NULL.

So what my files contained was a number of iso 8859-1 or latin1 characters like 0xe8 (è), 0xe0 (à), 0xf9 (ù) or 0xec (ì). It might also have been Windows-1252 but apparently the bytes between 0x80 and 0x9F didnt appear.

This is how to finally batch-convert character sets in filenames:

convmv -f latin1 -t utf8 --notest *.flac

I had some operas lying around amongst others Wagner's "Ring Des Nibelungen", Puccini's "La Boheme" and Verdi's "La Traviata". Sadly, some of them were not stored as flac but as monkey's audio (extension .ape) which is a non-free lossless codec but fortunately ffmpeg has a GPL'd decoder included. Additionally some CD's were stored as a single file with a cue sheet next to them.

So my task was: convert ape to flac, split audio by information from cue files and tag everything correctly.

These were the lines I used to split the audio:

ffmpeg -i CD1.ape CD1.wav
shnsplit -o flac -f CD1.cue -t "%a %n %t" CD1.wav
rm *pregap.flac CD1.wav CD1.ape
cuetag CD1.cue *.flac

First ape is converted to wav so that shnsplit can read it. Shnsplit will then take the timing information from the cue sheet and split the wav into chunks which it conveniently also converts to flac on the fly. Sadly it doesnt do tagging of those files so this is done by cuetag afterward with information from the cue sheet. You need the shntool and cuetools packages.

Other data was already existing as separate tracks and only had to be converted from ape to flac. Sadly flac offers no means for batch conversion but using a for loop and basename the same effect is created. Conveniently ffmpeg will copy the tags from the ape files to the new flac files as well.

for f in *.ape; do b=`basename $f .ape`; ffmpeg -i "$b".ape "$b".flac; done

The resulting flac files were about 3-5% larger than the ape files which is a totally acceptable tradeoff for being able to ditch an unfree format.

thomasg pointed out to me, that using the zsh there is an even neater way to do this loop without basename(1) and without some shell-loop keywords:

for f in *.ape; ffmpeg -i $f $f:r.flac

I was like so surprised how easy it is to install debian from an usb stick :D

curl http://http.us.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/boot.img.gz | zcat > /dev/sdc
mount /dev/sdc /mnt
( cd mount; wget http://cdimage.debian.org/debian-cd/6.0.2.1/i386/iso-cd/debian-6.0.2.1-i386-netinst.iso; )
umount /mnt

bam!

There is an interesting amount of ways to do that. First line is encoding, second line is decoding.

using python:

python -m base64 -e < infile > outfile
python -m base64 -d < infile > outfile

using openssl (-a is short for -base64):

openssl enc -a -e < infile > outfile
openssl enc -a -d < infile > outfile

using base64 (part of the coreutils package):

base64 < infile > outfile
base64 -d < infile > outfile

using perl:

perl -MMIME::Base64 -ne 'print encode_base64($_)' < infile > outfile
perl -MMIME::Base64 -ne 'print encode_base64($_)' < infile > outfile

using uuencode (but adds a header and footer):

uuencode -m - < infile > outfile
uudecode < infile > outfile

Has it even been done before? Searching the internet only finds huge manned solar boats.

Swimming around the earth with solar power should be much easier than flying as one doesnt have to worry about the night (really? see below). Another advantage is, that nations tend to try and protect their airspace whereas swimming through international waters should be fine.

The idea is, to have an autonomous robotic vessel, powered by photovoltaic means and two underwater propellers and doing navigation with gps. While shipping around the world, it would be great to have photos from all the exotic coastlines the robot approached. Image analysis could also be used to avoid getting too close to potential obstacles in the water.

There would be two possible routes. Either hoping to get through panama and suez canal together with other ships (and try not to get stuck by the canal sides) or swimming around cape horn and cape of good hope.

Having an uplink to the vessel would be great and certainly very useful but there doesnt seem to be any solution for satellite navigation that doesnt cost a fortune, isnt a huge installation and works around all the globe? Such an uplink would make lots of things much easier and would avoid loosing the robot.

A quick mockup of how such a robot could look like:

SVG source

Open questions:

• What about corrosion of the propeller/motors due to salt water?
• What about extreme temperatures? will the electronics cope with that?
• Could something cover the solar panels? Ice? Dirt?
• What about the Night? Build in batteries to keep it powered? Would the robot drift away?
• Are there currents too strong for the robot to overcome?
• Will motors wear out?
• Will someone find it and take it away?
• Is it legal?
• Go through suez/panama canal? How to avoid getting stuck there?
• Could it strand on a coast or riverside being stuck in plants or rocks?
• Enough power from solar cells? How large do they have to be?

EDIT:

Apparently people are already into this:

• http://www.engadget.com/2012/03/15/swimming-robots-break-record/
• http://www.bbc.co.uk/news/technology-17367984
• http://liquidr.com/files/2012/03/PacX_World-Record_03_13_12.pdf
• http://www.engadget.com/2011/11/19/wave-glider-robots-set-out-to-explore-the-seven-seas-break-the/
• http://news.cnet.com/8301-13772_3-57327023-52/ocean-faring-robots-set-sail-on-guinness-record-attempt/
• http://liquidr.com/