タグ：テレビの記事一覧

1. はじめに

 

2013年11月に交換(設置)したUSBハードディスク(USB-HDD)は、37型の液晶テレビ(東芝レグザREGZA)の録画用として、我が家の居間で動作していました。が、このところ、どうも録画に飛びが発生したり、予約した番組がきちんと録画されていなかったりと、怪しい動きをしていたのです。

 

このUSBハードディスクの機種に交換(設置)してから5年半が経過したため、そろそろ寿命かな？と考えていた矢先に、突然、「ハードディスクを認識しない」という現象が発生しました。

 

取説(取扱説明書)を見ながら、テレビ側の設定をいろいろ調べてみたのですが、どうもうまくいきません。

 

しかし、このまま放っておくわけにもいかず、しかたなく、新しいUSBハードディスク(USB-HDD)を買いに、近くの家電量販店まで足を伸ばしたのでありました。

 

☆　☆　☆

 

さて、取り外したUSBハードディスクは、ひとまず、そのままにしておいたのですが、以前、同じように故障した録画用のUSBハードディスクを、PCに接続して、その状態を確認したこと [1] を思い出し、今回も、「ダメ元」で、同じ手順で状態を確認したときに、どうなるかを実際に確認してみることとしました。

 

その結果、運良くというか、ハードディスクのファイルを修復し、USBハードディスクをテレビに接続して再び録画・再生をすることができました。

 

この記事では、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について試みた方法と手順を簡単なメモ書きですが、紹介します。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

2. 確認手順の概略

 

(1) Linuxパソコン(PC)を準備する

(2) USB-HDDをマウントし、マウントボイントを確認する

(3) USB-HDDをアンマウントし、ディスクチェックを行なう

(4) USB-HDDのディスクファイルの修復を行なう

(5) USB-HDDを再度マウントしてファイルのリストを確認する

(6) 再度アンマウントしてディスクチェックを行なう

 

これだけですが、(4)の作業でエラーになるか、ならないかがひとつの鍵になります。ちなみに、以前に書いた記事[1]の場合は、ここでNG(修復不能)と判断しました。

 

3. パソコン(PC)で外付けUSBハードディスク(USB-HDD)の状態を確認する

 

準備するものは、Linuxを起動できるパソコン(PC)と故障した(？)外付けUSBハードディスク(USB-HDD)とUSB接続ケーブルです。

 

液晶テレビ(東芝レグザREGZA)に接続されるUSBハードディスクのファイルフォーマットは
xfs形式になります。一般に使用されているWindowsパソコンでは、このxfsフォーマットのドライブやファイルを認識できません。したがって、Linuxを起動できるパソコン(PC)が必要なのです。

 

必ずしもPC本体にLinuxがインストールされていなくても、CD-ROMドライブなどから起動用CDなどでLinuxを起動できるのであれば問題ないとおもわれます。
(私自身のPCは、WindowsとLinuxのデュアルブートに設定してあるので、Linuxで起動しています。)

 

CDからLinuxを起動する方法は、ここでは触れませんが、[2]などを参考にして、起動用CDの作成、パソコン(PC)のCD-ROMドライブからの起動を行なって下さい。

 

以下、私の環境では、パソコン(PC)は東芝dynabook(PB552FEA127A51)、OSはLinuxでFedora29(64bit)、を使用しています。

 

まず、パソコンに外付けUSBハードディスク(USB-HDD)を接続します。

 

この状態で、外付けUSBハードディスクが認識されているかどうかを確認します。
デスクトップ上に、該当するハードディスクのアイコンが表示されれば、認識され、
マウントされている状態になっています。

そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクが存在するかを確認します。

 

次に、どのデバイスファイルにマウントされているかという、マウントポイントを確認します。例えば、/dev/sdb1 などになります。

 

以下はコマンド操作になりますので、コマンドライン端末(ターミナル)ウィンドウを開いて、管理者権限でコマンドを打ち込みます。

 

次に、いったんアンマウント(マウントを解除)して、ハードディスクの状態チェックを行います。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1　　( または　xfs_check /dev/sdb1 )

です。

すると、次のような表示がでてきました。

 

[root@localhost user01]# umount /dev/sdb1

[root@localhost user01]# xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

Phase 2 - using internal log

- zero log...

- scan filesystem freespace and inode maps...
bad magic # 0x6e93bf6a in inobt block 16/3

expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3

bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

bad starting inode # (6410804566 (0x10 0x7e1d1d56)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 7195546658)

--- (途中、省略) ---

bad starting inode # (4750678384 (0x10 0x1b299970)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4502697197)

ir_freecount/free mismatch, inode chunk 16/207729901, freecount 1704223958 nfree 33

badly aligned inobt rec (starting inode = 5277979757)

bad starting inode # (5277979757 (0x10 0x3a97946d)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6257491054)

--- (途中、省略) ---

bad starting inode # (4976999758 (0x10 0x28a6fd4e)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4315432406)

ir_freecount/free mismatch, inode chunk 16/20465110, freecount 107526891 nfree 34

badly aligned inobt rec (starting inode = 6034583137)

bad starting inode # (6034583137 (0x10 0x67b06e61)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 5675287099)

--- (途中、省略) ---

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4294967296)

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152
sb_fdblocks 52700857, counted 52709049

- 21:34:45: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan (but don't clear) agi unlinked lists...

found inodes not in the inode allocation tree

- 21:34:45: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 30

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 13

- agno = 14

- 21:34:53: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 21:34:53: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 21:34:53: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 30

- agno = 31

- 21:34:53: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Inode allocation btrees are too corrupted, skipping phases 6 and 7

No modify flag set, skipping filesystem flush and exiting.

[root@localhost user01]#

 

これで、一応、ハードディスクの状態確認ができたことになります。最後のほうに、「iノード割り当てBツリーが破損しているため、フェーズ6と7をスキップします。変更フラグを設定せず、ファイルシステムのフラッシュをスキップして終了します。」のメッセージで終わってしまいましたが、これは、ファイルの一部が破損していることを示しています。

 

4. 外付けUSBハードディスク(USB-HDD)のディスクファイルの修復を行なう

 

次に、修復できるかどうかをやってみました。使用するコマンドは、

xfs_repair -Lv /dev/sdb1

です。

 

ここで、以前経験したような fatal error が出現したら、物理的な故障なので、
どうしようもありません。

 

今回は、次のような表示がでてきました。

 

[root@localhost user01]# xfs_repair -Lv /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

- block cache size set to 332184 entries

Phase 2 - using internal log

- zero log...

zero_log: head block 199805 tail block 199805

- scan filesystem freespace and inode maps...

bad magic # 0x6e93bf6a in inobt block 16/3
expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3
bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

--- (途中、省略) ---

ir_freecount/free mismatch, inode chunk 16/73979246, freecount 889473186 nfree 31

badly aligned inobt rec (starting inode = 7924286411)

bad starting inode # (7924286411 (0x10 0xd85303cb)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6393507745)

--- (途中、省略) ---

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152

sb_fdblocks 52700857, counted 52709049

- 21:37:17: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan and clear agi unlinked lists...

found inodes not in the inode allocation tree

- 21:37:17: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 14

- 21:37:25: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 21:37:25: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 21:37:25: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 26

- 21:37:25: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

Phase 5 - rebuild AG headers and trees...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 31

- 21:37:25: rebuild AG headers and trees - 32 of 32 allocation groups done

- reset superblock...

Phase 6 - check inode connectivity...

- resetting contents of realtime bitmap and summary inodes

- traversing filesystem ...

- agno = 0

--- (途中、省略) ---

- agno = 31

- traversal finished ...

- moving disconnected inodes to lost+found ...

Phase 7 - verify and correct link counts...

- 21:37:25: verify and correct link counts - 32 of 32 allocation groups done

XFS_REPAIR Summary Tue Apr 30 21:37:25 2019

Phase Start End Duration

Phase 1: 04/30 21:37:06 04/30 21:37:06

Phase 2: 04/30 21:37:06 04/30 21:37:17 11 seconds

Phase 3: 04/30 21:37:17 04/30 21:37:25 8 seconds

Phase 4: 04/30 21:37:25 04/30 21:37:25

Phase 5: 04/30 21:37:25 04/30 21:37:25

Phase 6: 04/30 21:37:25 04/30 21:37:25

Phase 7: 04/30 21:37:25 04/30 21:37:25

Total run time: 19 seconds

done

[root@localhost user01]#

 

今回は、Phase1、Phase2、・・・、Phase7　と進んでいき、終了した(「done」)との表示でした。

 

もしも、この操作の実行中に、

 

Phase 1 – find and verify superblock…

superblock read failed, offset 0, size 524288, ag 0, rval -1

.

fatal error — 入力/出力エラーです

 

のような表示が出た場合は、それはハードディスクの物理的な故障なので、どうしようもありません。

 

5. 外付けUSBハードディスク(USB-HDD)のファイルリストの確認と再度のディスクチェックを行なう

 

さて、これで修復されたとのことなので、ファイルの存在と状態を確認してみました。いったん、再度マウントを行ないます。

デスクトップ上に、該当するハードディスクのアイコンが表示されれば、マウントされている状態になっていますが、そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクを確認します。(クリックすればマウントされます。)

 

今回の場合、
/dev/sdb1
のマウントポイントは、
/run/media/user01/e4f007b8-c779-4d7a-a2db-34c15c363213
でした。

そのディレクトリまで進み、ファイルの存在状態を確認しました。

 

[root@localhost user01]# cd /run/media/user01

[root@localhost user01]# ls

e4f007b8-c779-4d7a-a2db-34c15c363213

[root@localhost user01]# cd e4f007b8-c779-4d7a-a2db-34c15c363213

 

コマンドは「ls -al」です。

 

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# ls -al

合計 1742544948

drwxr-xr-x. 3 root root 53248 4月 30 12:30 .

drwxr-x---+ 3 root root 60 4月 30 21:46 ..

-rw-r--r--. 1 root root 82344 4月 30 12:30 .toshiba_dir_info_e89d874cd80a

-rw-r--r--. 1 root root 4760 4月 30 11:59 .toshiba_serieslist_e89d874cd80a

-rw-r--r--. 1 root root 268 4月 30 12:30 .toshiba_size_info_e89d874cd80a

drwxr-xr-x. 7 root root 109 11月 6 2014 .toshibazze89d874cd80a

--wsr-sr-t. 1 root root 7052292288 11月 14 2013 M000020131114195750e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 4月 27 15:20 M000020131114195750e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 80778 11月 14 2013 M000020131114195750e89d874cd80a.dtv.rat

--wsr-sr-t. 1 root root 5232187584 11月 27 2013 M000020131127195950e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 2月 24 14:52 M000020131127195950e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 65826 11月 27 2013 M000020131127195950e89d874cd80a.dtv.rat

--- (途中、省略) ---

--wsr-sr-t. 1 root root 2524987584 4月 30 12:00 M000020190430115950e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 4月 30 12:00 M000020190430115950e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 41046 4月 30 12:30 M000020190430115950e89d874cd80a.dtv.rat

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]#

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# cd .toshibazze89d874cd80a

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin

-rw-r--r--. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]#

[root@localhost .toshibazze89d874cd80a]# cd log

[root@localhost log]# ls -al

合計 188

drwxr-xr-x. 2 root root 97 4月 22 10:59 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 51200 3月 17 22:59 00000064.dat

-rw-r--r--. 1 root root 51200 4月 6 10:33 00000065.dat

-rw-r--r--. 1 root root 51200 4月 22 10:59 00000066.dat

-rw-r--r--. 1 root root 27008 4月 30 12:30 00000067.dat

-rw-r--r--. 1 root root 11 4月 22 10:59 info.dat

[root@localhost log]#

[root@localhost log]# cd ..

[root@localhost .toshibazze89d874cd80a]# cd alkf

[root@localhost alkf]# ls -al

合計 60

drwxr-xr-x. 2 root root 4096 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.bin

-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.buc

-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.bin

-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.buc

-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.bin

-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.buc

-rw-r--r--. 1 root root 32 11月 4 2013 ald.bin

-rw-r-----. 1 root root 32 11月 4 2013 alk.bin

[root@localhost alkf]#

[root@localhost alkf]# cd ..

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin

-rw-r--r--. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]# cd aeef0000000

[root@localhost aeef0000000]# ls -al

合計 520

drwxr-xr-x. 2 root root 8192 4月 29 16:00 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 8月 28 2018 aee00000000.bin

-rw-r--r--. 1 root root 80 3月 7 2017 aee00000001.bin

-rw-r--r--. 1 root root 80 6月 25 2014 aee00000002.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 2月 15 2017 aee0000007e.bin

-rw-r--r--. 1 root root 80 3月 1 2017 aee0000007f.bin

[root@localhost aeef0000000]#

[root@localhost aeef0000000]# cd ../aeef0000001

[root@localhost aeef0000001]# ls -al

合計 500

drwxr-xr-x. 2 root root 8192 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 12月 5 20:15 aee00000080.bin

-rw-r--r--. 1 root root 80 8月 5 2015 aee00000081.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 12月 3 2017 aee000000ff.bin

[root@localhost aeef0000001]#

[root@localhost aeef0000001]# cd ../aeef0000002

[root@localhost aeef0000002]# ls -al

合計 140

drwxr-xr-x. 2 root root 4096 4月 27 15:22 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 2月 27 20:15 aee00000101.bin

-rw-r--r--. 1 root root 80 3月 3 23:25 aee00000103.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 5月 14 2018 aee00000137.bin

[root@localhost aeef0000002]#

 

以上のように、修復されたファイルの状態を確認することができました。

 

最後に、もう一度、アンマウント(マウントを解除)して、ハードディスクの状態チェックを実施しました。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1

です。

 

[root@localhost ~]# umount /dev/sdb1

[root@localhost ~]# xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

Phase 2 - using internal log

- zero log...

- scan filesystem freespace and inode maps...

sb_fdblocks 52700857, counted 52709049

- 22:13:57: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan (but don't clear) agi unlinked lists...

- 22:13:57: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 14

- 22:14:05: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 22:14:05: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 22:14:05: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 2

--- (途中、省略) ---

- agno = 31

- agno = 1

- 22:14:05: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Phase 6 - check inode connectivity...

- traversing filesystem ...

- traversal finished ...

- moving disconnected inodes to lost+found ...

Phase 7 - verify link counts...

- 22:14:05: verify and correct link counts - 32 of 32 allocation groups done

No modify flag set, skipping filesystem flush and exiting.

[root@localhost ~]#

 

特に、問題はなさそうです。

 

この状態の外付けUSBハードディスク(USB-HDD)を液晶テレビ(東芝レグザREGZA)のUSB録画端子に接続して状態を確認したところ、再び録画・再生をすることができました。

 

6. まとめ

 

以上、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について
試みた方法と手順を簡単なメモ書きですが、紹介しました。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

------------------------------------------------------------------
References

[1] 液晶テレビに接続したUSBハードディスクの故障と対策 (2013/11/10)

[2] 「HDD認識しない」パソコンでレグザUSBハードディスクを復旧・修復 – レグザREGZA研究 (2014/09/28)
------------------------------------------------------------------

 

(2019-5-2)

 

 

 

いまさらだが、1960年から1970年代に流行した歌(JPOP ? )が妙に懐かしい。

 

最近、街角のちょっと大きめの本屋さんなどには、CDに収めた 20-30年前の歌謡曲やらポップスやらがワゴンに入れられて売られているのをよく目にする。ちょうど、我々の中学から高校時代のものなので、よけいに懐かしくなる。

以前はレコードなどで販売されていたものも、最近、リイッシュー(再編集)されてCDとして店頭に並ぶのであろう。

 

当時、音楽といえば、テレビやラジオの歌番組が主な情報源であった。農山村のことなので、レコード店も自宅とはかなり離れた町(市の中心部)に時間をかけて買いに(探しに)いかないと、なかった時代であった。

 

友人たちのなかにはカセットテープレコーダを持っている者もいた。ラジオやレコードから録音して聞いていたのだとおもう。また、当時の本屋さんにあった、歌謡曲を中心に編集されている雑誌に出ている歌詞や楽譜を見ながら、お気に入りの歌を覚えようとしたものであった。

そして、それらに似せて、自分自身で詞や曲を作り、譜面化したものであった。

 

もう、かなり前のことなので、記憶に定かでない部分もあるが、友人の結婚式に、友人の作詞、自分の作曲で作った歌を提供したこともあった。

 

当時の印象に残る歌としては、岸洋子の「希望」「夜明けのうた」、シューベルツの「風」、寺山修司・杉田二郎(ジローズだったか?)の「戦争を知らないこどもたち」などなど。

 

でも、これぞという曲に限って、店先にあるCDではなかなか見つからないものなのだが、探して見たい曲である。

 

 

考えて見れば、昔はレコード盤(EP、LP)、カセットテープに収められて販売されていた歌が、いまはCD、DVD、インターネットのダウンロードと大きく変遷している。レコードやカセットテープを使っていた世代においては、懐かしさは当たり前の感情なのかもしれない。

 

(2009-2-21)

 

 

 

衝撃的な内容の詩を目にした。ふだんの、ごくあたりまえの幸せな毎日が、明日も続くとは限らない。この詩を読んで、衝撃を受けるとともに日常の生活について、考えさせられてしまった。

 

2001年9月11日の同時多発テロの追悼集会やテレビなどで朗読されたという。この詩は、アメリカのノーマ・コーネット・マレックさんという女性の方が、わが子を亡くした時に書いた詩だそうだが。みなさんはどのように感じられるのだろうか。

 

詩は、If I knew it would be the last time (最後だとわかっていたなら)... から始まる。

 

全文は、次のサイトなどに掲載されている。

 

(英語) Tomorrow Never Comes (written by Norma Cornett Marek)

 

あるいは

 

(日本語) 最後だとわかっていたなら

 

(2009-2-7)

 

 

===================================

以下は引用

===================================
(英語) Tomorrow Never Comes (written by Norma Cornett Marek)

 

Tomorrow Never Comes

written by Norma Cornett Marek in 1989

Printed with permission.

 

If I knew it would be the last time

that I'd see you fall asleep,

I would tuck you in more tightly

and pray the Lord, your soul to keep.

 

If I knew it would be the last time

that I see you walk out the door,

I would give you a hug and kiss

and call you back for one more.

 

If I knew it would be the last time

I'd hear your voice lifted up in praise,

I would videotape each action and word,

so I could play them back day after day.

 

If I knew it would be the last time,

I would spare an extra minute or two

to stop and say"I love you,"

instead of assuming you would know I do.

 

If I knew it would be the last time

I would be there to share your day,

Well I'm sure you'll have so many more,

so I can let just this one slip away.

 

For surely there's always tomorrow

to make up for an oversight,

and we always get a second chance

to make everything right.

 

There will always be another day

to say"I love you,"

and certainly there's another chance

to say our"Anything I can do's?"

 

But just in case I might be wrong,

and today is all I get,

I'd like to say how much I love you

and I hope we never forget,

tomorrow is not promised to anyone,

young or old alike.

And today may be the last chance you get

to hold your loved one tight.

 

So if you're waiting for tomorrow,

why not do it today?

For if tomorrow never comes,

you'll surely regret the day

that you didn't take that extra time

for a smile, a hug, or a kiss,

and you were too busy to grant someone,

what turned out to be their one last wish.

 

So hold your loved ones close today,

whisper in their ear,

tell them how much you love them

and that you'll always hold them dear.

 

Take time to say"I'm sorry,"

"please forgive me,""thank you," or"it's okay."

And if tomorrow never comes,

you'll have no regrets about today.

 

===================================

 

 

 

(日本語) 最後だとわかっていたなら

 

「最後だとわかっていたなら」

ノーマ コーネット マレック作

佐川睦訳

 

あなたが眠りにつくのを見るのが

最後だとわかっていたら

わたしは　もっとちゃんとカバーをかけて

神様にその魂を守ってくださるように

祈っただろう

 

あなたがドアを出て行くのを見るのが

最後だとわかっていたら

わたしは　あなたを抱きしめてキスをして

そしてまたもう一度呼び寄せて

抱きしめただろう

 

あなたが喜びに満ちた声をあげるのを聞くのが

最後だとわかっていたら

わたしは　その一部始終をビデオにとって

毎日繰り返し見ただろう

 

あなたは言わなくても

わかってくれたかもしれないけれど

最後だとわかっていたら

一言でもいい・・・「あなたを愛してる」と

わたしは　伝えただろう

 

たしかにいつも明日はやってくる

でももしそれがわたしの勘違いで

今日ですべてが終わるのだとしたら

わたしは今日

どんなにあなたを愛しているか　伝えたい

 

そして　わたしたちは　忘れないようにしたい

 

若い人にも　年老いた人にも

明日は誰にも約束されていないのだということを

愛する人を抱きしめられるのは

今日が最後になるかもしれないことを

 

明日が来るのを待っているなら

今日でもいいはず

もし明日が来ないとしたら

あなたは今日を後悔するだろうから

 

微笑みや　抱擁や　キスをするための

ほんのちょっとの時間を

どうして惜しんだのかと

忙しさを理由に

その人の最後の願いとなってしまったことを

どうして　してあげられなかったのかと

 

だから　今日

あなたの大切な人たちを

しっかりと抱きしめよう

そして　その人を愛していること

いつでも

いつまでも大切な存在だと言うことを

そっと伝えよう

 

「ごめんね」や「許してね」や

「ありがとう」や「気にしないで」を

伝える時を持とう

そうすれば　もし明日が来ないとしても

あなたは今日を後悔しないだろうから

===================================

 

 

十年一昔(じゅうねんひとむかし)というが、時の流れを感ずる。

 

というのも、これまで、仕事や趣味で携わってきたコンピュータの移り変わりを思い出してみると、よくわかる。

 

いまは、ウィンドウズXPやビスタが全盛であるが、私がコンピュータに直に触れたのは、1978年頃、当時の米国コモドール社製の8ビットのもので、BASICという言語でプログラムを自作し、機器の制御やデータ収集に使用していた。

 

5インチのフロッピーディスクはよく読み込みエラーを起こし、プログラム自体もたまに暴走するという信頼性に欠けるものであった。

 

その後、日本のN社がPC8001というマイコン(バソコンとも呼んでいたが)を市場に売り出しした。信頼性は格段に向上したが、価格は一式80万円くらいした。もちろん、まだまだとても個人で買えるものではなかった。

 

1980年代前半はまだ8ビットマイコンが残っていたが、16ビットが主流の時代になった。しかし、まだ、BASIC言語でプログラミングしていたが、メーカー各社の仕様が統一されていなくて困ったものである。

 

仕様統一のきっかけとなったのが、MSXの登場であったとおもっている。MSXは1983年ごろ登場し、価格が安く4-6万円くらいで本体が買えて、家庭のテレビに簡単に接続でき、BASIC言語でプログラムを自作できるほかに、ソフトメーカーからもMSX仕様のソフトウェアが売り出されていた。

 

ここにきて、ようやく個人でコンピュータが持てる時代になったのであった。その後、32ビットの時代になり、OSもウィンドウズ3.1、95、98、2000と変化していった。

 

いままで、自宅で個人で購入し、使用したコンピュータを数えてみると、MSX、MSX2、Dynabook、Libretto、ThinkPadとそれぞれに想い出がある。

 

 

ことしの一月にパソコンのＯＳを入れ替えた。それまでウィンドウズ98を使用していたのだが、ウィンドウズ98用のウイルス対策ソフトがもうサポートされないことになってしまったため、やむなくXPを入れることにした。それでも、もういまはビスタの時代になってしまった。

 

時の流れははやいものである。

 

(2008-9-20)

 

 

(追記)

 

正確にいうと、MS-DOSというオペレーションシステムが先にできていた。これは16ビットのコンピュータ用のものであった。MSXは8ビットのコンピュータであるが、MSX-BASIC というものが先に共通仕様化されてできていた。16ビット用のMS-DOSと同じように8ビット用として作られたのが MSX-DOS であった。フロッピーディスクの形式は2DDが主流であったが、MS-DOS上でもデータの読み書きができる優れたものであった。

 

 

当時、私は、職場では16ビットのコンピュータで、家では8ビットのMSXで、同じフロッピーディスクを持ち運びして仕事を処理していたことを覚えている。

 

(2008-10-18 追記)