ラベル gigabeat の投稿を表示しています。 すべての投稿を表示
ラベル gigabeat の投稿を表示しています。 すべての投稿を表示

2009年1月7日水曜日

Compile error of Rockbox's sendfirm.c with libmtp0.3[Ubuntu8.10][libmtp0.3]

作業環境はUbuntu8.10。検索で来たWindowsユーザはこの記事見ても無意味だと思います。悪しからず。

gigabeatSにRockboxをインストールするには、現時点(20090107)では全て手動でコンパイル〜ファームウェア書き込みを行わなければいけないみたい。同じgigabeatでも、FやXシリーズは解析/開発されきってインストールユーティリティのソフトが用意されているのだけど、まだSシリーズは開発途上。

まだ実際にgigabeatSにRockboxをインストールした訳ではないのだけれど、作業時に必要になるsendfirmプログラムをコンパイルする時点で躓いたのでちょっと書いておく。

sendfirmにはlibmtpが必要になるので、
$ sudo apt-get install libmtp-dev
こんな感じでlibmtpのdevelopmentパッケージをインストールしておく。

http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInstallation#A_Compile_the_sendfirm_utility
Rockbox wikiのgigabeatSへのインストール指南に書かれている通りに、現行ビルド一覧ページ(http://build.rockbox.org/)からソースコードをDL。
アーカイブを展開し、端末でその中のutils/MTPディレクトリに入りmakeすると、sendfirmがコンパイルされる。
rockbox-3.1/utils/MTP$ make
gcc -Wall -lmtp -o sendfirm sendfirm.c
sendfirm.c: In function ‘sendfile_function’:
sendfirm.c:94: error: too many arguments to function ‘LIBMTP_Send_File_From_File’
make: *** [sendfirm] エラー 1
$

LIBMTP_Send_File_From_File関数への引数が多すぎるとエラーを吐かれてしまった。

これはどういうことだろうと思い、ソースを見てみる。
エラーが出ているsendfirm.cの94行め付近は
ret = LIBMTP_Send_File_From_File(device, from_path, genfile, progress,
NULL, parent_id);
となっていて、6つ引数が与えられているのが分かる。
で、Ubuntuのリポジトリから落ちてくるlibmtpのver0.3のソースを見てみる。
http://libmtp.sourcearchive.com/documentation/0.3.0/group__files_g552e760a429b0e47a593b8ade20bb763.html#g552e760a429b0e47a593b8ade20bb763
int LIBMTP_Send_File_From_File(
LIBMTP_mtpdevice_t * device,
char const *const path,
LIBMTP_file_t *const filedata,
LIBMTP_progressfunc_t const callback,
void const *const data
)
与えるべき引数の数は5つだ。そりゃエラーになる筈。

今度はver0.2系のソースを見てみる。
http://libmtp.sourcearchive.com/documentation/0.2.1/group__files_gfaf21159580eef716b24da3a257b3060.html#gfaf21159580eef716b24da3a257b3060
int LIBMTP_Send_File_From_File(
LIBMTP_mtpdevice_t * device,
char const *const path,
LIBMTP_file_t *const filedata,
LIBMTP_progressfunc_t const callback,
void const *const data,
uint32_t const parenthandle
)
こっちは6つになってる。
つまり、libmtpのver0.2系(0.1系も引数は6つだった)を考えて書かれたソースだったのね。

んでまぁ、libmtpの0.2系を持ってきてやるのが正当なんだろうけど、面倒なのでいらなそうな6つ目の引数を削除してみる。sendfirm.cの94行め付近「device, from_path, genfile, progress,NULL, parent_id」となってる箇所からparent_idを抜いて、「device, from_path, genfile, progress, NULL」としてから、改めてmake。
rockbox-3.1/utils/MTP$ make
gcc -Wall -lmtp -o sendfirm sendfirm.c
sendfirm.c: In function ‘sendfile_function’:
sendfirm.c:67: 警告: unused variable ‘parent_id’
$
警告出たけど、案の定parent_idが宣言されたけど一度も使われてないよ、ということなのでキニシナイ。

まぁ、肝心のこっから先をやってないんだけどね。

2009年1月5日月曜日

Happy New Year!/[memo]Rcokbox for gigabeat S/Leap second error of Zune&gigabeat

明けましておめでとうございます。
いきなりですが、暫くの間1日1更新できるか怪しくなります。だって、大学の方で卒論の締切りが迫ってきてますから。。。

というわけで、今日のところはちょっと覚書程度に愛機gigabeatSをRockbox化するために必要なページをbookmark。

Gigabeat S Port - Rockbox
http://www.rockbox.org/twiki/bin/view/Main/GigabeatSPort

Rockbox for Gigabeat S
http://audio-p.hp.infoseek.co.jp/

今までMTPデバイスとして扱う方法をいろいろ試してきましたが、Rhythmboxで楽曲を転送した時にVideoフォルダに入れられるという新たな不具合に出くわし、いよいよRockbox試してみるかという心境になったのです。


ところで、閏秒問題について

Zuneとgigabeatが閏年の処理の問題でフリーズ
http://slashdot.jp/it/article.pl?sid=09/01/01/1247219

記事中ではgigabeatのTとVのシリーズしか触れられてませんが、それらと同じPortable Media Centerをファームウェアとして使っているSシリーズも同じ症状で固まりました。もうサポート終わってるとはいえ、除け者にしなくたっていいじゃない(´・ω・`)
症状は起動画面から進まない、とかの筈らしいんですが、私のは故障メッセージが出てたのでこの問題とは関係なく故障したのだと思ってました。以前にも同じメッセージが出て修理に出したことがあったので、さっくり諦めたわけですハイ。
でも、閏秒後にバッテリを放電しきった後に再起動〜〜という対処法を行ったら何故か直っちゃいました。。。(実際にはバッテリが悪くなってるので勝手に放電しきってしまったのですが)

2008年12月20日土曜日

How to use mtp-albumart command[mtp-tools][Ubuntu8.10]

GigabeatSを、Ubuntu上でlibmtpを使ったソフトで接続する際は、必ず一度USBケーブル繋ぎなおし&GigabeatSの電源入れ直し(本体下の主電源スイッチではない)しないと、次の接続セッションを開始することが出来ない。これはもう仕様と思って諦めるとして、接続セッションを極力切らずにやれば少しでも楽になるはず。

と言うわけで、あるもので間に合わせる限り、GigabeatSに音楽CDアルバムを取り込む場合の最低限の手順はこんな感じじゃないかと。
既にCDのリッピング/楽曲ファイル作成は済んでいるとします。mtp-sendtrコマンドは一曲ずつしか転送出来ないので使いません。

  1. Rhythmboxでファイルをまとめて転送

  2. GigabeatS繋ぎ直し

  3. mtp-tracksコマンドで楽曲ファイルのIDを調べる

  4. GigabeatS繋ぎ直し

  5. mtp-albumartでアルバム情報作成&アルバムアート転送

こんな感じでしょうか。

Rhythmboxでの操作は、楽曲一覧から転送したい曲をまとめて選択しつつGigabeatSのアイコン(何故か旧iPod Nanoアイコン)にドラッグ&ドロップしてやるだけです。

mtp-tracksコマンドはGigabeatSを繋いだ状態で、
$ mtp-tracks > tracklist.txt
と打って、mtp-tracksの表示結果がtracklist.txtに保存されるようにします。tracklist.txtをgeditあたりで開いて、アルバム分けしたいトラックのIDだけを別にメモしときます。GigabeatSにトラックを転送したのが新しい順番になってるので、転送したばかりのは上のほうにあるはずです。

mtp-albumartコマンドは
$ mtp-albumart 
libmtp version: 0.3.0

You need to pass a filename.
Usage: albumart -i <fileid/trackid> -n <albumname> <imagefile>
で、usageを見る限り1曲ずつしかIDを指定できなさそうですが、実は複数イケます。こんなんソース見ないとわかんねぇよ。。。(http://libmtp.sourcearchive.com/documentation/0.3.4/albumart_8c-source.html)
今回、Number Girlのベストアルバムで試したんですが、こんな感じで指定してやる必要がありました。カレントディレクトリにアルバムアートのファイル(Folder.jpg)があるとします。
$ mtp-albumart -i 16778654 -i 16778655 -i 16778656 -i 16778657 -i 16778658 \
-i 16778659 -i 16778660 -i 16778661 -i 16778662 -i 16778663 -i 16778664 \
-i 16778665 -i 16778666 -i 16778667 -i 16778668 -i 16778669 -i 16778670 \
-i 16778671 -n "OMOIDE IN MY HEAD 1~BEST & B-SIDES~ [Disc 1]" ./Folder.jpg
IDは私のGigabeatSに実際に転送した際に割り振られたもの。いちいち-iオプションをすべての番号の前に付ける必要がありますが、少なくともmtp-albumartコマンドではこれで複数ファイルを指定できます。

地味に面倒くさいのが、IDを抽出する作業という。

2008年12月17日水曜日

libmtpの覚書

Amarokで同期できなかったので、仕方なく久方ぶりにWindowsXPを起動してWMPで同期しようとしたら、Microsoft Updateやらウィルススキャンやらが勝手に動いてまともに使えやしない。
おまけにWMPはGripでリッピングしたmp3のタグが読めないと来たもんだ。

結局Rhythmboxで転送したよ orz
アルバム分けしてくれないのが難なんだけどね。Amarokではアルバム分けしてくれるのになぁ。

少なくとも、一度GigabeatSとの接続セッションを切ると、デバイスを接続しなおさなきゃ(ソフトウェア上の操作でなく、実際にUSBケーブルを抜き差しする)再接続できないみたい。
同じlibmtpを使っていても、接続セッションを保ちつづけるソフトなら使えるが、一度何かを実行する度セッションを切ってしまうような物は少なくとも私のGigabeatSでは使えないだろう。mtp-toolsも結局一つ一つ別々のコマンドだから、シェルスクリプトで扱うにも駄目だろう。

GigabeatSでは、楽曲ファイル転送時に一緒に送るタグ情報のアルバムの項目には目もくれない。曲の転送とは別にアルバム情報のデータをGigabeatS上に作成してやらなきゃアルバム分けしてくれない。曲ファイル単体のタグの中のアルバム情報と、MTPデバイス上で扱うアルバム情報が明確に分けられている。そしてGigabeatSでは後者だけを使用する仕様みたい。

mtp-albumartコマンドでGigabeatS上の曲ファイルにアルバムアートを付加してやると、何故アルバム分けしてくれたのかというと↓

mtp-albumartコマンドのソースはこれらしい
http://libmtp.sourcearchive.com/documentation/0.3.4/albumart_8c-source.html
本来はlibmtpに付いてくるサンプルコードみたい。

このコード中では、LIBMTP_Create_New_Album関数でアルバム情報をデバイス上に作成してから、そのアルバム情報に対して、LIBMTP_Send_Representative_Sample関数でアルバムアートのデータを転送している。

アルバムアートを扱う専用の方法があるんじゃないかと思い込んでいたのだが、Send_AlbumArtみたいな関数は存在しない
Representative_Sampleというのは、アルバムを「代表するサンプル」という名前の通り、そのアルバムについてのサンプルとなる情報を設定するものだそうだ。要するに、サムネイル(アルバムアート)とか、プレビュー用に楽曲のサビの部分だとかを扱うもの。(参考:MTPの仕様書 http://www.usb.org/developers/devclass_docs/MTP_1.0.zip)
それが今回の場合はアルバムアートという訳。
LIBMTP_Send_Representative_Sample関数の説明を読むと、iRiverやCreativeのデバイスでもJPEGデータ(要するにアルバムアート/サムネイル)を扱うらしい。

ちなみにこのコードでは、既にアルバム情報が存在しているかどうかを確認せずに、必ず新たにアルバム情報を作成している。なので、コマンドを実行する度に新たなアルバムが出来る。まったく同じ内容を指定して実行すると、まったく同じ内容が作成されるだけだ。

既に存在している場合にそのアルバム情報を更新するには、LIBMTP_Get_Album_List,LIBMTP_Get_Album,LIBMTP_Update_Album,あたりの関数を使えば良いだろう。


libmtpのサイトを見ると、libmtpを使ったソフトの例が載っている。
http://libmtp.sourceforge.net/downstream.php

RhythmboxやAmarokなどのソフトや、RubyとPython向けのlibmtpのwrapperもある。

2008年12月16日火曜日

GigabeatS syncs with Amarok

以下のエントリを書いて、一晩明けたら同期できなくなっていた。
なんなんだよチキショウ

機嫌があるのか

- - - - - - - -

AmarokでGigabeatSに同期出来るようになってました。
以前にやった時は全然だめだったんですけど、いろいろアップデートされたんでしょうねぇ。

Rhythmboxでファイルを転送した場合みたいに、タグからアルバムだけ抜けてたりせずに、ちゃんと同期してくれます。

ただ一つ難点が。
アルバムアートもちゃんと同期してくれるのは嬉しいんですが、Gigabeat上で見るアルバムアートが何故か著しく画質が著しく劣化しています。
試しに、mtp-albumartコマンドでアルバムアートを転送してみたりしましたが、そちらでは元のファイルの画質そのままにでした。

せっかくすっきり転送出来るのに絵が汚いのはなんだかなぁ……
いっそ転送用スクリプトを自分で書くのが早いか……

2008年9月13日土曜日

mtp-sendtrコマンドでgigabeatSに転送してみた[mtp-tools]

<追記>
mtp linux なんちゃら……でググってきた人へ
mpt-***コマンドの使い方を間違えてる気がするので、以下の内容はあくまで参考にしてください。
なんとなく、こうするんだろうなー、というのは分かっちゃいるんですが、本腰入れて試せていません orz

MTPデバイスであるgigabeat Sにmtp-sendtrコマンドを使ってmp3ファイルを転送してみたテスト。
(本文中では言ってないけど、ひとつコマンド実行する度に一度PCから外さなきゃ次が実行できない妙な問題のせいで、無駄に時間食ってます。)

転送してみたファイルはこちらからいただきました
http://www.teslakite.com/freemp3s/paprika/

$ mtp-sendtr Desktop/byakkoya-no-musume.mp3 Music/
libmtp version: 0.2.6.1

PTP: Opening session
Desktop/byakkoya-no-musume.mp3,Music/,(null),(null),(null),(null),00,0
Sending track Desktop/byakkoya-no-musume.mp3 to Music/
type:mp3,1
Title> 白虎野の娘
Album> パプリカ
Artist> 平沢進
Genre>
Track number>
Year> 2006
Length> 287
Sending track:
Codec: ISO MPEG-1 Audio Layer 3
Title: 白虎野の娘
Album: パプリカ
Artist: 平沢進
Year: 2006
Length: 287
Sending track...
Progress: 4593804 of 4593804 (100%)
New track ID: 16778596
PTP: Closing session
$

これで、mp3ファイルは確かに転送が出来たし、再生も大丈夫だった。
ただ、いくつか問題があったので、書き留めておく。

基本的に楽曲ファイル自体のID3v3などメタデータは読まずに、そういったタイトル情報などはファイル転送時に一緒にデバイス側に伝える様。
エラーメッセージと共に表示されるmtp-sendtrのusageはこんな感じ。
usage: sendtr [ -D debuglvl ] [ -q ] -t <title> -a <artist> -l <album>
-c <codec> -g <genre> -n <track number> -y <year>
-d <duration in seconds> <local path> <remote path>

上記の実行結果のとおり、<local path>と<remote path>だけを与えた場合でもコマンドは通るが、途中でタイトル情報など訊かれる。これは、飛ばしちゃっても良かったりする。
ただし、gigabeat側の問題だと思うのだが、アルバム情報だけは認識してくれず、gigabeat上では「アルバム情報なし」となってしまっていた。この問題にはWindows+WMP環境で使っていた時も悩まさせられた。

また、<remote path>に与える、転送先のgigabeat内でのパス指定がよく分からなかったので、とりあえずgigabeat内のMusicディレクトリという意味で「Music/」としてみたつもりだったのだけれど、実際に転送されたファイルはgigabeat内の「Pictures/My Music/Music」というファイルパスになってしまっていた(Musicという名のファイルとして転送して保存されてしまった)。Rhythmboxで転送した時もそうだったが、なぜか有無を言わさず「Pictures/My Music/」に転送されてしまう。Picturesディレクトリと同階層にMusicディレクトリがあり、Win環境でWMPを使い転送した場合はそちらに入る。libmtpに問題があるのだろうか?

それと、アルバムアートは別途mtp-albumartコマンドで転送する必要がある。
Usage: albumart -i <fileid/trackid> -n <albumname> <imagefile>
このコマンドを実行する前に、MTPデバイス中でのファイルのIDを調べる必要がある。トラックIDとファイルIDの2種類あるがどちらでも、良いらしい。
トラックIDを調べるなら、mtp-tracksコマンド
ファイルIDを調べるなら、mtp-fileコマンド
でそれぞれ、MTPデバイス内のトラック/ファイルの詳細な一覧が出力される。その中にIDも書かれているので、それを使う。
出力結果をファイルに書き出して、テキストエディタでファイル名/タイトルで検索するのが楽だろう。
$ mtp-tracks > trackslist.txt
Track ID: 16778596
Title: 白虎野の娘
Artist: 平沢進
Origfilename: Music
Track number: 0
Duration: 287000 milliseconds
File size 4593792 bytes
Filetype: ISO MPEG-1 Audio Layer 3
Use count: 2 times

こんな感じで出力されるので、16778596をmtp-albumartコマンドで使うわけだ。
$ mtp-albumart -i 16778596 -n "パプリカ" albumart.jpg

これで、gigabeat側でアルバムアートが表示できるようになった。しかも、mtp-albumartコマンドを使うとアルバム情報が上書きされるのか、「アルバム情報なし」だったのがちゃんと「パプリカ」と表示されるようになった。
でも、画像が劣化してる気がするのには目を瞑っとこう……

2008年8月30日土曜日

メタデータが壊れたMP3ファイルへの対処[ffmpeg]

ネットで自作の曲なんかを配布してるのはよくある話だけども、最近落としたmp3ファイルのメタデータがおかしくて、ちょっと難があった。
エンコーダのいたずらか、はたまたダウンロード時にエラーになっただけなのかはわからないが、実再生時間とメタデータに書かれてる再生時間が違っていて、PC上のプレーヤでは難なく再生できていたのだが、gigabeatに転送したらエラーを吐かれて再生できない、ということがあった。

そこで私が取った行動はコレ
$ ffmpeg -i broken_metadata.mp3 -acodec copy extracted_audio.mp3

メタデータだけがおかしい様だったので、Audioストリームだけを抽出して新たなmp3ファイルを作成。

いやぁffmpeg使えるなぁ。
あとはWMV3のエンコードに対応してくれるとありがたいのだけれども。

2008年8月27日水曜日

UbuntuでMTPデバイスを扱う[Amarok][mtp-tools][mtpfs]

20081216編集
注意Ubuntu8.10上で同期できるっぽいです。

---------------------

以前のエントリでも書いたように、Ubuntuでもgigabeat(MTPデバイス)を使うことができる。

その時に試したのはRhythmboxでだった。そのエントリ中でも書いたように、IDv2タグをgigabeatが見てくれないという問題があるのだが、実はさらにアルバムアートが同期できないという問題もあった。

後者の問題に対して、他のプレーヤで何とかならないだろうかと思い、Amarokを導入してみた。
$ sudo apt-get install amarok
本体だけでは肝心のmp3など音楽ファイルが再生できないので、Amarokが自動でlibxine1-ffmpegパッケージをインストールしてくれる筈なのだが、私の場合は手動でインストールした。つか、インストールしないと固まる固まる。
("amarok mp3"とかでググると、libxine1-pluginsをインストールする、という記事が見つかるが古い情報なので注意。libxine-pluginsをapt-get installしようとしたら「それ古いからlibxine1-ffmpeg入れてね」とメッセージが出た。)
Amarokの初回起動時には、楽曲コレクションの初期設定などのダイアログが表示されるので、お好みでデータベースを選んだりする。

Amarokにgigabeatを認識させるにはまず、Amarokのメディアデバイスの設定画面で「メディアデバイスを追加」から現れるダイアログで、プラグインにはMTPデバイスを選択、適当な名前を付けて「OK」ボタンを押す。

マウントポイントなどさらに詳細に設定できるようだが、とりあえずこれで下準備は完了。

MTPデバイスを接続した状態で、デバイスブラウザで接続ボタンを押せば自動で認識してくれる筈。(完了まで多少もたつくが我慢我慢)


そして、さっそくファイルを転送してみよう…………出来ない orz
手順は間違っていない筈なのに何故だろう? と思い、さらに他の手段を探すことに。

そこで今度はSynapticsでmtp-toolsというのを見つけて、インストールしてみた。
$ sudo apt-get install mtp-tools
これは端末でMTPデバイスと通信出来るコマンドをいくつも提供してくれる。
mtp-albumart     mtp-files        mtp-newfolder    mtp-thumb
mtp-albums mtp-folders mtp-newplaylist mtp-tracks
mtp-connect mtp-format mtp-playlists mtp-trexist
mtp-delfile mtp-getfile mtp-reset
mtp-detect mtp-getplaylist mtp-sendfile
mtp-emptyfolders mtp-hotplug mtp-sendtr
例えば、mtp-detectを使うと、MTPデバイスの詳細情報を検出してくれる。

しかし、gigabeatをPCに接続して一番最初の接続しかgigabeatが受け付けてくれない、という妙な症状が起こってしまった。
mtp-detectをやった後に他のコマンドでgigabeatと通信しようとしてもエラーが出て、接続できない。これはAmarokも同じ様で、一度接続を解除するとUSBケーブルを一度外してからでないと接続しなおせなかった。

mtp-toolsもAmarokもMTPデバイスとの通信にlibmtpというライブラリを利用しているのだが、libmtpの設定ファイル(/etc/udev/rules.d/45-libmtp7.rules)がおかしいのか、libmtp自体のバグか何かなのかは分からない。Rhythmboxもlibmtpを使っている様なのだが、同じ症状は現れない。。。
Rhythboxで同期した楽曲ファイルが、何故かgigabeatのPicturesフォルダに入るのと関係があるのだろうか?

とりあえず、Ubuntuのリポジトリのバージョンは0.2.6.1なのだが、最新のものは0.3に上がっているので、次の機会にそちらを手動で導入してみようかと思う。

そして、結局アルバムアートは同期できないまま orz

<おまけ>
mtpfsを使うと、mtpデバイスをマウントできる。
$sudo mtpfs /media/gigabeat/ -o allow_other
(/media/gigabeatディレクトリは先に作成しておくこと)

<追記>
文中でパッケージ名を間違えてたのを修正。

ググって来た人、こちらも見た方がいいかも
mtp-sendtrコマンドでgigabeatSに転送してみた[mtp-tools]
http://mstssk.blogspot.com/2008/09/mtp-sendtrgigabeats.html

<追記2>
一番上にも書き加えましたが、2008年12月16日でUbuntuのリポジトリからDL出来る各ソフトウェア(Ubuntu8.10/Amarok/libmtp)の最新バージョンでは同期できる?
http://mstssk.blogspot.com/2008/12/gigabeats-syncs-with-amarok.html

2008年8月18日月曜日

UbuntuでgigabeatS


Ubuntu 8.04にデフォで入ってるRhythmboxプレイヤーはMTPデバイスと楽曲の同期が出来るプラグインが入ってる。だが、以前に手持ちのgigabeat S30で試してみた時にはRhythmboxがフリーズしてしまい、結局諦めたのだった。
それで、gigabeatに楽曲を同期するときだけWindows XPを立ち上げるという面倒くさいことをやっていたのだが、昨日ふと思い立って再び試してみたら、、、ありゃイケたよオイ(´・ω・`)

接続時にモタつくのはgigabeatがあくせくしてるわけだからいいとして、曲の転送時にフリーズしたりするのはまぁご愛嬌か。やり直すと大抵うまくいく。転送する時は曲の再生を止めるとかちょっと気をつかわなきゃいけないかもしれない。

ちなみに転送の方法は、上の画像みたいにデバイスのアイコンが表示されるので、自身の楽曲ライブラリのところから転送したい曲をドラッグアンドドロップすればいい。

それよりも躓いたのはタグ情報についてだ。
手持ちのmp3ファイルを試しに転送してみたところ、何故かタグのアルバム情報がgigabeat上では「不明」になっている。
転送時のエラーなんかではなく、曲データ自身に問題がある様。同じようなことがWindowsでWMPから転送した時にも起こったことがあるのを思い出した。

んで、原因としては、Ubuntuのソフト(RhythmboxやEasyTagとか)で見てるタグ情報とgigabeatで見てるタグ情報が違っている、という感じみたい。

解決法としては、やはりEasyTagで、タグをID3v2書き込みのみにしていたのをID3v1でも書き込むように設定を変更し、目的のmp3ファイルを一度読み込んで強制保存する。これで、ファイルにID3v1のタグが追加される。
ID3v1ならgigabeatでもちゃんと読み込んでくれるので、これでおk。

<訂正>やっぱダメだった。

<追記>
ID3v2タグでなくてWMAには別にメタデータがあって、gigabeatなんかはそいつを見てる様。
それと、Rhythmboxで転送したファイルは何故か、gigabeat内のPicturesディレクトリ以下に保存されてしまった。本来はMusicに入るはず。

この記事の続き
UbuntuでMTPデバイスを扱う[Amarok][mtp-tools][mtpfs]
http://mstssk.blogspot.com/2008/08/ubuntumtpamarokmtp-toolsmtpfs.html