Wednesday, November 24, 2010


早期我用Windows時,用光碟備份了很多中文檔名的文件。當時還沒有Unicode,所以檔名是以Big5編碼。在Linux下,如果mount CD時沒有指定原編碼系統,所有的Big5中文檔名會被視為raw ASCII,直接轉成utf-8。比方說,檔名 台北.txt 就變成 ÑxÑ_.txt


$ echo ÑxÑ_.txt | iconv -t 437 | iconv -f big5

437是extended ascii。

2013/09/26更新:另可參考 提出的以下工具:

env LANG=C 7z x
convmv -f big5 -t utf8 --notest -r . # for filename which is big5 coded

env LANG=C 7z x
ls | iconv -t iso-8859-1 | iconv -f gb2312 # verify this is the right conversion sequence
convmv -f utf-8 -t iso-8859-1 --notest -r . convmv -f gb2312 -t utf-8 --notest -r .

Tuesday, July 20, 2010

Moving files with symbolic link vs. cross-filesystem

In linux, I mounted a raided lvm in /mnt/raid/home and bind it to /home. I also have /mnt/raid/shared/Music and other directories to be shared across users. Within my personal directory /home/username, there are some a few symbolic links to /mnt/raid/shared/Music and other shared directories.

This way, my media files can be accessed by all local users -- it also makes backing up of personal files (as opposed media files) easier.

The problem is, when moving files in or out of those shared folders, Linux mv can not resolve the complicated symbolic path -- what it sees are files across file systems. Therefore, a simple mv is translated into cp and rm, rather than simply updating the node info.

The solution is to translate everything to absolute path. Here's a simple script to do that.


use Cwd 'abs_path';

foreach my $arg (@ARGV)
    next if ($arg =~ /^-/); # skip switches
    $arg = abs_path($arg);
    $arg =~ s|^/home/|/mnt/raid/home/|;

system("/bin/mv", @ARGV);

This alone is enough for my environment. You may want to have more substitution rules for a more complex setting.

Monday, March 15, 2010

Scorewriters (Music Notation Program)

A friend asked me to recommend a scorewriter and I'd like to share some of my personal experiences.

I had used various scorewriters, from a very early version of Copyist (1988), Encore, Overture, and then settled on Finale for more than a decade, before switching to Sibelius 6.1 lately. Every switch was motivated by the new features provided, except for the last switch, motivated by Sibelius' promotional price, which I started to look for due to Finale's licensing restriction.

Long story short, I am very glad that I made the switch. Sibelius, with its younger age, has less historical burden that Finale bears -- Finale was the pioneer program that made scorewriting possible on personal computers, but some of its designs do not (or not soon enough) include newer technological advances such as newer UI design philosophy, better MIDI capability, more flexible audio routing and manipulation, etc.

Thursday, February 11, 2010

Fixing Yamaha PSR Keys

Some keys (G2 - C3) on my old 61-key Yamaha PSR keyboard quit working so I spent a Sunday afternoon fixing it. It took me a while to figure out what the problem was. I share what I learned here, so perhaps somebody out there can save their old keyboards, too.

Dissecting the keyboard was pretty straightforward -- just unscrew everything on the bottom of the keyboard.

Underneath the keys that our fingers press are a layer of rubber buttons that short the switches.

For each key, there are two buttons to short two different switches. These buttons have different heights (or depths) so when a key is pressed, button A will hit switch A, and then button B will hit switch B. The time difference is determined by the velocity at which the key is pressed. This is why they call these velocity-sensitive keys.

Since F=ma (Newton's 2nd law of motion), m is constant, and the depth difference of the buttons is also a constant, it means the harder we hit the keys, the higher acceleration the keys move, and the shorter the time it will take button B to hit switch B, after button A hits switch A first. With normalization (depending on how the sound samples are handled), this timing difference can be interpretated as intended dynamic.

The mechanism of the keyboard is a very clever design. Now I need to figure out what's wrong with those keys. The fact that keys in a row stopped working at the same time is a strong hint that they must share a common signal path. Originally I thought there must be some complicated multiplexing to encode all the keys to optimized output points. However, on this circuit board there are only simple diodes for each switch; no binary encoding.

I noticed switch A and switch B both connect to the same contact that I first thought to be the common ground -- that way, we would need 61 keys * 2 switches = 122 output points.  However, attached to the lower half of the keyboard are two ribbon cables: 7 pins and 12 pins; and the upper half has another 4 pins, and shares the same 12 pins on the lower half via parallel connection. This is far less than the output points we need.

After carefully tracing the circuits, I realize the design is actually musical!  All A switches of note A in every octave are connected to the same output. All A switches of note B in every octave are connected to the same output.  The same for B switches. We would then expect a ribbon cable of 24 pins since there are 12 tones in one octave and each tone has switch A and B. However, it turns out that every 6 pairs of switch A/B share the same ground. Since 6 semi-tones equal half octave, a tritone, I call such grounds "tritone set number".

Now the numbers add up. And it became obvious that the bad keys (G2-C3) share tritone set #3 (the lowest note C2 alone is tritone set #1; C#2-F#2 is tritone set #2).  Tracing the path, I found some contacts' rust broke the circuit line.

I ended up having to jump short, with a wire, the ground of tritone set #3 to pin 3 of the tritone ribbon cable. It was not easy to solder wires to old printed circuits so I had to get creative. Anyway, by making use some of the unused holes on the board and some glue, I was able to keep the wires in place and brought those keys back to life.