2009/11/14

Androidでのミュージックファイルアートワーク(カバーアート)仕様

 

正確にはAndroidの仕様なのかアプリケーションの仕様なのか分からないが、少なくともHT-03Aの標準音楽プレーヤと、meridianでは以下のような動作になっていた。

  • アートワークはアルバムごとに1つ

「アルバム」の定義は後述するが、上記の意味するところは、同一アルバム内の楽曲ファイルに異なるアートワークを設定したとしても、プレーヤ上はどれも同じアートワークが表示される。

どのアートワークが用いられるかは

  • アルバム内で最初にアクセスした「アートワークが設定されたファイル」のアートワークを、アルバムアートワークとしてキャッシュする

ということのようだ。一旦キャッシュされると、次回以降はそのキャッシュを使用しているように見える。

  • キャッシュはルート直下のalbumthumbsディレクトリに保存される

このディレクトリ以下に保存されているファイルを画像ビューアで開くと、アートワーク画像そのものだということがわかる。

 

次に「アルバム」の定義だが、

  • 異なるディレクトリに保存されたファイルは必ず異なるアルバムとして扱われる
  • 同一ディレクトリに保存されたファイルでも、ID3タグ上のアルバム名が異なるファイルは異なるアルバムとして扱われる

逆に言うと、

  • 同一アルバムとして扱うためには、以下の条件を満たす必要がある
    • 同一ディレクトリに保存されたファイルである
    • ID3タグのアルバム名が同一である

ということになる。

 

ところで、HT-03Aでの楽曲管理にdoubleTwistを用いている方も多いと思うが、このアプリで同期すると音楽ファイルは単一ディレクトリに保存される。

したがって、アルバム名を設定していないと、全て同一アルバムの楽曲だとみなされてしまう。

ipumではニコニコ動画音楽ファイルにID3タグを付与する設定にしていても、アルバム名の設定は行わない。このため、初回アクセスしたファイルのアートワークが、全てのファイルで表示されてしまう。対策としては

  • ファイルごとに保存ディレクトリを変える
  • ファイルごとにアルバム名を変える(ファイル名をアルバム名に設定する、など)

といったことが考えられるが、前者はファイル管理が煩雑になる(し、同期アプリに依存する)、後者はAndroid上だけで扱うファイルであれば良いかもしれないが、タグの本来の意味と異なるものを設定することになるため、相互運用で問題が出るだろう。

 

追記:

Google code の Issuesでは、Issue 2945: Music player doesn't recognize different images in the id3 tags of multiple files in one album で”Defect”として登録されているので、仕様ではなくバグのようだ。

| | コメント (0) | トラックバック (0)

ニコニコ動画のRSS一覧作成するGroovyスクリプト

 

最近全くGroovyを触っていなかったので、手慣らしにスクレイピングでニコニコ動画のRSS一覧を作成するスクリプトを書いてみた。

import org.cyberneko.html.parsers.SAXParser
 
def rankUrl = 'http://www.nicovideo.jp/ranking'
def kinds = ['総合':'fav', 'マイリスト':'mylist', '再生':'view', 'コメント':'res']
def spans = ['毎時':'hourly', 'デイリー':'daily', '週間':'weekly', '月間':'monthly', '合計':'total']
 
def rankHtml = new XmlSlurper(new SAXParser()).parse(rankUrl)
 
def groups = rankHtml.'BODY'.'DIV'.'DIV'.'TABLE'.'TR'.'TD'.'TABLE'.'TR'.'TH'.'A'
def groupMap = [:]
groups.each{groupMap[it.text()] = it.@href.toString().split('/')[6]}
//groupMap.each{println it.key + ', ' + it.value}
 
 
println '<HTML><BODY>'
 
for(kind in kinds){
    for(span in spans){
        println '<A HREF="' + rankUrl + '/' + kind.value + '/' + span.value + '/' + 'all' + '?rss=2.0">'
        println '' + 'カテゴリ合算' + ' - ' + kind.key + ' - ' + span.key + '</A><BR>'
    }
}
 
 
for(group in groupMap){
    def groupUrl = rankUrl + '/fav/daily/' + group.value
    def groupHtml = new XmlSlurper(new SAXParser()).parse(groupUrl)
    def categories = groupHtml.'*'.'*'.'*'.'*'.'*'.'*'.'*'.'*'.'*'.'NOBR'.'A'
    def categoryMap = [:]
    categories.each{categoryMap[it.'DIV'.text()] = it.@href.toString().split('/')[6]}
    //    categoryMap.each{println it.key + ', ' + it.value}
 
 
    println '<P>'
    println '<H3>カテゴリグループ: ' + group.key + '</H3><BR>'
    for(category in categoryMap){
        for(kind in kinds){
            for(span in spans){
                println '<A HREF="' + rankUrl + '/' + kind.value + '/' + span.value + '/' + category.value + '?rss=2.0">'
                println '' + category.key + ' - ' + kind.key + ' - ' + span.key + '</A><BR>'
            }
        }
    }
    println '</P>'
}
println '</BODY></HTML>'

出力結果はこういう感じになる。

実行にはCyberNeko HTML Parserが必要。

| | コメント (0) | トラックバック (0)

2009/11/13

音楽ファイルに投稿者を設定する(ipum ver.0.3)

NicoBrowser ver.0.1.1 でニコニコ動画の投稿者名を永続化するように対応したのに合わせ、ipumで変換したファイルのID3タグにも投稿者名を埋め込むように対応した。

ダウンロードはこちらから。

従来、ニコニコ動画サイトで投稿者命を取得するには、各動画ページ内の「この動画を違反通報」リンク先を参照する必要があり、他の方が作成されているスクリプト等ではこれを見ているものが多いように思う。

この秋のバージョンアップからだろうか、動画ページ内に「投稿者プロフィールへ」リンクが出来ているようなので、NicoBrowserではこちらから取得するようにしている。

| | コメント (0) | トラックバック (0)

ipum - 動画ファイルから無劣化音楽抽出

 

ipum_front

ipum 最新版(ver.0.3)をダウンロードする

Java6実行環境がインストールされていれば、ipum.jarをダブルクリックすることで起動できる。

 

機能と特徴

  • インターネット動画サービスが提供している動画ファイルから音楽を抽出する。
  • mp4,flv,swfファイルに対応。
    • 動画変換でよく利用されているffmpegはswfサポートが弱いので、swfに対応できているのは希少。
  • NicoBrowserとの連携により、ニコニコ動画のコンテンツではID3タグにサムネイル画像などを埋め込み可能。
  • 初期設定不要で、ドラッグアンドドロップで変換可能。
  • オリジナルの音質を保持して抽出するため無劣化、省容量。
  • 変換処理が無いので高速。

 

動作環境

java6実行環境がインストールされたWindows。

ID3タグ埋め込み機能を利用するためには、NicoBrowser Ver.0.1.1以降がセットアップされている必要がある。

    | | コメント (0) | トラックバック (0)

    データを保持したままテーブル構造を変更する(NicoBrowser ver.0.1)

     

    NicoBrowser Ver.0.1を作成した。ダウンロードはこちらから。

    なお、以前のバージョンから更新する際には、初回起動前に以下のコマンドを実行する必要がある(通常の起動コマンドにsyncオプションをつける)。

    java –jar NicoBrowser sync

     

    変更内容は以下の通り。

    • 永続化情報に「投稿者」を追加した。
    • 追加機能は特に無い。

     

    NicoBrowserでは、コンテンツ情報をインプロセスDBで管理している。今回、投稿者情報という新しい項目を永続化するに当たって、テーブルにカラムを追加する必要が生じた。

    従来のバージョンでは、JPAの機能を利用して、DBやテーブルが無ければ作成する(あれば何もしない)という動作にしていた。しかし、今回のように現在テーブルが既に存在する場合にプロパティ(永続化するBeanのフィールド)を追加しようとした場合は、この機能では対応できない。

    そこで、今回のバージョンからは、DB/テーブルの作成はLiquiBaseで行うことにした。

    LiquiBaseはDBリファクタリングツールという位置付けで、書籍「データベース・リファクタリング」で説明されている手法をツール化したもの、らしい。

    ともかく、このツールを使うことで、テーブルの内容を保持したままテーブル構造を変更することができるようになった。

    ただ、このツールは、DBの変更(リファクタリング)内容を、専用のテーブルで管理しており、NicoBrowserを従来のバージョンから今回の方式にあわせるためには、一旦現在の内容をその管理テーブルに書き込む必要がある。これを、冒頭に記載したsyncオプションで行うことにしている。

    このsyncオプションによる管理テーブルの同期は1回のみ行えばよく、今後はテーブル構造に変更があった場合でもLiquiBaseが自動で追従してくれるはずである。

    | | コメント (0) | トラックバック (0)

    NicoBrowser - ランキング、公開マイリストからのニコニコ動画自動ダウンロード

     

    NicoBrowser最新版(ver.0.1.1)をダウンロードする

    以前のバージョンを利用している場合には、後述「バージョンアップに関する注意事項」も参照のこと。

     

    機能・特徴

    • ニコニコ動画に投稿された動画の自動ダウンロード
    • ダウンロード履歴管理
      • 一度ダウンロードした動画は重複してダウンロードされない
      • エコノミーモードでダウンロードしていた場合でも、高画質ファイルが取得できるのであれば再ダウンロードする
    • Pure Javaで開発
      • Windows, MacOS, Linux上などで動作可能
      • Java6実行環境がインストールされている必要がある

     

    操作方法

    コマンドラインで以下を実行。

    java -jar NicoBrowser.jar

    NicoBrowser.jarのダブルクリックでも起動できるが、この場合エラーメッセージ等は表示されない。

    その他詳細設定方法などは、ダウンロードファイルに含まれるREADME.htmlを参照。

     

    バージョンアップに関する注意事項

    2009/05/24版以前を使用していた場合の注意事項

    アップデート後(つまり今回のファイルで上書きした後)、1回目の起動前に以下のコマンドを実行する必要がある。実行しないとDB関連のエラーとなり処理が継続できない。

    java -jar NicoBrowser.jar sync

    (引数にsyncをつけて実行する)

     

    2009/03/23版以前を使用していた場合の注意事項

    nicobrowser.propertiesの互換性は無いため、一旦リネーム(or 削除)してから
    実行する必要がある。こうすることで、新しいnicobrowser.propertiesが作成される。

    path.dbの設定は、従来は"ファイル名"の指定だったが、現在は"ディレクトリ名"の指定に変わっていることに注意。

    本体libディレクトリ以下について、構成が大きく変わっているため、libは上書きでなく置換することを推奨。

    | | コメント (0) | トラックバック (0)

    2009/11/09

    ニコニコ動画コンテンツをサムネイルつきで音楽ファイルに変換する(ipum ver.0.2)

    前回記載したとおり、iPod touchやHT-03Aでは専ら音楽を聴くのみで、動画再生機能は利用していない。

    ただ、せっかくディスプレイがあるので、音楽再生時にも利用できたほうが良いのではないか、ということで、ipumにアートワークを埋め込む機能を追加した。

    ドラッグアンドドロップで、以下のような情報が埋め込まれたファイルが自動生成される。

    id3tag

     

    この機能を利用するためにはいくつか制約がある。

    • NicoBrowser(使い方例1,2)でダウンロードしたファイルであること。
    • ダウンロード後、ファイル名を変更していないこと。

    NicoBrowserが持っているダウンロード履歴を基にWebアクセスを行い、ID3タグに埋め込むための情報を取得しているため、このような制約がある。

    その他、このipumのID3タグ埋め込み機能を利用する場合、NicoBrowserと同時起動すると正しく動作しないため、注意が必要である。

     

    ダウンロードはこちらから。

    デフォルトでは、本機能は無効になっている。有効にするためには、設定ファイル内の<useid3>オプションをfalseからtrueに書き換える。

    | | コメント (0) | トラックバック (0)

    2009/11/08

    動画から音楽ファイルを抽出するipum ver.0.1

    ipum_front

    ダウンロードはこちらから。

    Java実行環境がインストールされていれば、ipum.jarをダブルクリックすることで起動できる。

     

    機能と特徴

    • インターネット動画サービスが提供している動画ファイルから音楽を抽出する。
    • mp4,flv,swfファイルに対応。動画変換でよく利用されているffmpegはswfサポートが弱いので、swfに対応できているのは希少。
    • 初期設定不要で、ドラッグアンドドロップで変換可能。
    • 変換処理をはさまないため、音質の劣化や変化がなく、オリジナルのまま抽出可能。
    • 変換処理が無いので高速。

     

    動機

    最近使用しているポータブルミュージックプレーヤは、iPod touchと、たまにHT-03Aである。双方とも動画再生が行えるが、動画を再生することは殆ど無く、単純に音楽を聴くだけに使用している。

    YouTubeやニコニコ動画のflvやmp4を、ポータブルプレーヤ向けに変換してくれるソフトウェアは多いが、簡単に音楽ファイルに変換できるものは少ないように感じた。あったとしても動画変換のおまけ機能といった位置付けで、機能が無駄に多く、最適な変換を行うための設定が分からなかったりする。

    従来、私はCraving Explorerの変換機能を利用していたが、

    • 変換するだけのためにブラウザを立ち上げるのは...
    • オリジナルの音源を使えば良いのに変換処理が入ってしまう(時間がかかる、ものによってはファイルサイズが肥大化する)。
    • swfファイルの変換が出来ない。ファイルタイプをみて使用するソフトウェアを変えるのは面倒。

    という不満点があった。

    技術的には、ドラッグ&ドロップをJavaで実装したことが無かったのでやってみよう、というのと、Jakarta Commonsの便利さを実感してみよう、というのがある。

     

    現在の制約事項は以下の通り。

    • ウィンドウ右上の設定ボタンは機能しない。現在のところ、設定変更はファイルを直接編集する必要がある。設定ファイルは初回起動時に、ホームディレクトリ直下に.ipum/ipum.xmlとして作成される。WindowsXPの場合は C:\Documents and Settings\user\.ipum\ipum.xml となる。
    • 一旦登録したファイルは削除できない。これはただの実装漏れなので、近いうちに修正したい。
    • ファイル名によっては変換に失敗するものがある(ハートマークが入ったもので必ず失敗することを確認)。これはffmpegの制約のようだ。対策としては変換時、一時的にファイル名を変更するなどが挙げられる
    • 音楽ファイルフォーマット(エンコード方式)は変換元のファイル拡張子から決め打ちしているので、想定と異なるエンコードだと変換できても聴けないものが出てくるかもしれない。
    • 動作環境はJava6ランタイムがインストールされたWindows。ネイティブバイナリを使用していることの他、Javaでのdrag&dropの実装がOSごとに異なるらしい。

    | | コメント (0) | トラックバック (0)

    2009/11/06

    [読書]「科学者になる方法」 科学技術振興機構(JST)プレスルーム編

     

    本書「はじめに」より。

    進路に迷っている高校生の皆さんや、科学に興味を持っている方々が「理系に進んだらこんな仕事をするのか」、「研究者の日常生活はこうなのか」など、「研究者の実像」が分かるような本を作ってみようということになったのです。

    タイトルや掲載順は異なるが、原稿作成者はSciencePortalのページ「科学者になる方法」と同じであり、内容のイメージは掴める。おそらくwebにあるのが、原稿で、これを基にインタビューを行いまとめたものが本書なのだろう。

    研究分野ごとに章がわかれており、それぞれ以下の通りとなっている。

    1. 環境分野。2名。
    2. 情報通信分野。4名。
    3. ライフサイエンス分野。16名。
    4. ナノテクノロジー・材料分野。11名。

    webでは34名登場しているのに対し書籍では合計33名になっているのは、書籍では毛利衛氏の文章はコラムとして扱われているため。

    冒頭引用文及び、上記webのタイトルを一覧するとわかるが、本書は書籍名である「科学者になる方法」というより、『科学者の半生』という色が強い。

    この他、『○○先生の研究』という節でそれぞれの著者が行っている研究の概要を、『研究者になるなら-先生からのアドバイス』という節で研究者としての資質や、どう考え行動していくべきなのか等が記述される。この3節がこの書籍の構成になっている。

    研究分野の比率は前述のとおり情報工学分野は少ないため、研究内容についてはあまり関心が生まれなかった(全く無いというわけではなく、例えば野依良治氏の文章の中にある、鏡に映った右手の手袋から不斉合成の説明をされるくだりは大変面白かった)のだが、アドバイスの節は読んだ価値を感じさせてくれた。著者ごとに反対の意見とも言える主張をされているものもあり、面白い。

    途中のコラムに「研究者へのキャリアパス」というものがあり、ここでは、最終的な研究環境として『大学研究者』『公的研究機関』『企業研究者』の3種類が挙げられている。この書籍に登場されている方をカテゴライズしてみたところ、以下のようになった。

    1. 大学研究者: 25名
    2. 公的研究機関: 5名
    3. 企業研究者: 4名

    執筆の以来を行う際の伝手の問題なども影響しているのだろうが、やはり研究者になろうとした場合の正攻法は(おそらく世間のイメージどおり)大学研究者になることなのだろうか。

    | | コメント (0) | トラックバック (0)

    2009/11/05

    FEST-Swingを利用する(6) 非EDTでのSwingアクセスを検証する

    Swingのスレッドポリシーに記載されている通り、Swingコンポーネント及び関連クラスはイベントディスパッチスレッド(EDT)で実行する必要がある。

    スタンドアロンなプログラムを作成している場合には、上記リンク先に記載されているとおり、あまり意識する必要がない。しかし、クライアント/サーバ間で非同期通信を行うプログラムなどでは、よく誤ったコーディングを見かける。

    本エントリでは、上記問題の簡単な実例と、それに対するFEST-Swingでの検証方法について記述する。

     

    サンプルの説明

    今回のサンプルコードはこちらになる。本サンプルコードは、GUIを持つクライアント(client.Client)とサーバ(server.Server)が登場する。

    クライアントは、サーバに要求を行い、サーバからその結果を受けた際に、画面に結果を表示する機能を持つ。

    サーバは、クライアントからの要求を受け付けた後、非同期で処理を行い結果を通知する機能を持つ。

    cs_sequence

    (余談。JUDE/Community 改め astash* community、最近のバージョンでは、印刷やコピー時に、上図のような透かしが入るようになったようだ。あくまで試用版、という色合いが濃くなったということか。JUDEは2009年末までダウンロード提供、とのこと。)

     

    注目すべき箇所

    結果を表示するラベル(resultLabel)に文字列を設定している2箇所に注目する。

    1箇所目はclient/Client.javaの106行目requestButtonActionPerformed メソッド中になる。要求ボタンを押した際に実行される。

       1: private void requestButtonActionPerformed(java.awt.event.ActionEvent evt) {                                              
       2:     resultLabel.setText("要求中...");
       3:     server.request();
       4: }

    2箇所目は同ファイル134行目 listen メソッド中になる。サーバからの通知を受けた際に実行される。

       1: public void listen(String str) {
       2:     resultLabel.setText(str);
       3: }

    どちらも同じようにイベントハンドラの中でラベルに文字列を書いており、実行してみても通常問題は発生しないため、このような実装が行われているのをよく見かける。

    しかし実際は、一方は問題ないが、もう一方は冒頭記述のSwingスレッドポリシーに反している。

    1点目のメソッドはJButton#addActionListenerメソッドで登録したハンドラであり、これは、ボタンが押された場合にEDTで実行されることが保証されている。

    一方、2点目のメソッドはサーバ側のタイミングで実行される(今回の場合はサーバスレッドが実行する)。従って非EDTで実行されてしまっている。

     

    FEST-Swingを用いた検出

    FEST-Swingでは、上記のようなコーディング誤りを検知する方法を提供している。FailOnThreadViolationRepaintManagerというクラスがこれに当たる。

    利用するには、JUnitのテストクラスの@BeforeClassで以下の1行を追加すればよい。

       1: @BeforeClass
       2: public static void setUpClass() throws Exception {
       3:     FailOnThreadViolationRepaintManager.install();
       4: }

    サンプルコードのテストケースを実行してみると、例外EdtViolationExceptionが発生し

    Exception in thread "Server Thread" org.fest.swing.exception.EdtViolationException: EDT violation detected

    から始まる例外スタックトレースによって、前述2点目のハンドラに問題があることが検知できる。

    ただし、JUnit自体は正常終了している。これは、前回記載した事項と同様で、JUnitを失敗させるためには、JUnitスレッドで例外を送出する必要がある。

    実際のプログラムでは、あらゆるスレッドやプロセス(通常、クライアントとサーバは別VMだろう)で発生した例外をJUnitスレッドに集約することはできないだろう。ただし、ユニットテスト時、このようなテストにはモックオブジェクトを使用するのが通例だと考える。従って、モックオブジェクトのスレッドで発生した例外を、前回のようにJUnitスレッドに教えるコードを追加すれば正しく問題を検知できるテストコードが作成できると考える。

    FailOnThreadViolationRepaintManagerを用いた検証は完璧ではない(これについては次回記載予定)のだが、十分役に立つのではないだろうか。

    | | コメント (0) | トラックバック (0)

    Enum<?>にキャストしようとするとコンパイルエラー"変換できない型"が発生する

    こちらの例にあるように、

    public class Test {
        enum Planet { EARTH, MARS }
     
        public static void main(String[] args) {
            Enum<?> e1 = Planet.EARTH;
            // Hmm, doesn't compile
            Planet e2 = (Planet) e1;
            // Well this compiles, but it's not pretty!
            Planet e3 = (Planet) (Object) e1;
            // So does this ....
            Planet e4 = (Planet) (Enum) e1;
        }
    }

    をコンパイルすると、7行目(Enum<?>の部分)で"変換できない型(inconvertible types)"というエラーが発生する。

    どうやら原因はSun JDK6のバグだそうで、JDK7では解消されている。

    今回のようなバグは、Eclipse上で開発を行ってEclipseのコンパイラを使い続けていると全く気付かず、さあjarに固めようか、といってAntでjavacすると...というようなタイミングで発覚するので性質が悪い。

    NetBeansなら保存時の自動コンパイルでも(少なくともWindowsでは)デフォルトでSunコンパイラを使用するため、早期発見しやすいのではないかと思う(最終成果物はSunコンパイラでコンパイルすることが大半だろう、という前提の下で)。

    一応、Eclipseもビルダーの設定を行えば保存時コンパイルにSun JDKを使用するようにも出来るようだが。

    | | コメント (0) | トラックバック (0)

    2009/11/04

    TrlLogEditor 1.1

     

    trlフォーマットファイルの編集ツールTrlLogEditorだが、Ver1.0aでは速度表示において、特定の条件下で誤差を含む値を表示していたため、これを修正した。

    TrlLogEditor.jar Ver.1.1をダウンロードする

    前回、

    ファイルフォーマットを独自で解析している都合上、このプログラムで保存したファイルが正しくない結果になる可能性がある。

    というように記載したが、他の方の解析結果も同様なので、間違いは無いのではないかと思う。

    | | コメント (0) | トラックバック (0)

    Holux m-241のtrlファイルフォーマット

    以前予告したとおり、trlファイルについて記述しようと思ったのだが、既に日本語でも解説されているサイトが複数あるようなので、繰り返し説明する必要がないと考え、解説サイトの紹介にとどめる。

    それぞれ、自作ユーティリティやスクリプトも公開されている。

    | | コメント (0) | トラックバック (0)

    2009/10/29

    ニコニコ動画(9)になってニコニ・コモンズカテゴリが廃止された

    ネットニュースなどでは見かけなかったのだが、ニコニコ大百科を見ると、以前作成していたRSSフィード一覧の中ではニコニ・コモンズひとこと動画カテゴリが廃止されたようだ。

    ニコニコ動画(9)のバージョン移行に伴い、カテゴリタグとしての機能が廃止された。

    その他の新設・廃止されたカテゴリタグについても記載があった

    このカテゴリのRSSフィードや、今回新しく出来たカテゴリグループランキングRSSフィード(従来どおり、URLの後ろに?rss=2.0をつけhttp://www.nicovideo.jp/ranking/fav/daily/g_popular?rss=2.0 のような形になっているようだ)も、NicoBrowser 2009/05/24版で対応できているように見える。

     

    ところで、上記のようなシステム寄りの設計を以って、「汎用性・拡張性が高い」と主張する意見を、業務で何度か聞いたことがある。

    しかしながら、個人的にはユーザビリティを無視してシステムの都合だけで決めたようなインタフェースに対して、より価値が高いように聞こえる上記意見は、聞くたびに疑問に思っていた。

    何が言いたいかというと、NicoBrowserって使い勝手微妙ですね、ということだけなのだが。

    | | コメント (0) | トラックバック (0)

    転居時のNTTフレッツ光解約はそんなに面倒ではなかった

    転居時に一番大変なのは、ごみの処理についてではないかと考える。

    粗大ごみ(大型ごみ)はあらかじめ自治体へ回収の申し込みを行い、コンビニ等で粗大ごみ処理券を購入した上で、指定された日時に指定された場所へ出しておく必要がある(東京都新宿区の例)。

    また、自治体によっては、回収点数や回収間隔に制限を設けている場合もある(千葉県市川市の例)。

    1回の申し込みで5点まで収集します。申し込みの間隔は7日間以上あけてください。

    その他、上記例の中に記述されている通り、テレビ・冷蔵庫など(家電リサイクル法による)PCなど(資源有効利用促進法による)は、粗大ごみとして扱えないため、別途会衆を依頼するなどの作業が必要である。

    可燃ごみ等の通常ごみについても、一度に大量のものを出すことはマンションの取り決めなどで禁じられていることもあり、計画的にごみ出しを行わないといけない場合がある。

    民間のリサイクル業者に任せると上記の問題が解消される場合もあるが、いわゆる悪徳業者の判別が必要になるだろう(東京都練馬区)。

    チラシなどの宣伝で、「家庭で不要になった家具等の粗大ごみを処分する」などと言って、高額な処理費用を請求したり、無料で引き取るといいながら、処理費用を請求する業者がいますので、ご注意ください。(粗大ごみは、区の収集(申込制・有料)に出すのが正しい処分の方法です。)

    引越し業者によってはごみ処理サービスを提供しているところもある(ハート引越センターの例)が、業者を決めてからごみ処理方法を考えるのは、時期的に厳しくなったり、金銭面で有利に働かなかったりするのではないかと思う。

    …とここまで書いたが、今回の私の転居では粗大ごみは1つも出さなかった(普通ごみを引越しのかなり前から小分けにして出したくらい)ので、自治体に相談すれば案外簡単に解決する問題である、という可能性もある。ただし、上記のような背景があると知った上で、なるべく早めに行動する必要はあるだろう。

     

    一方で、GIZMODO JAPANの記事にある、NTTフレッツ光の解約はそんなに大変ではなかった。

    以前のエントリでは記載し忘れていたが、転居に伴い新聞購読の解約も行った。

    電気・水道・ガス会社とは異なり、インターネット接続や新聞は、ある地区で複数のサービス提供会社が並存する、つまり競争が発生する。

    また、今までインターネット接続や新聞購読のサービスを受けていた人は、転居後も速やかに同サービスを受けたいと考えるのではないかと思う。

    従って、転居の連絡時に、転居先でも同社の契約を続ける提案を行うのは、どちらから見てもメリットになることが多いのではないかと思う。

    実際、私の転居の際も、NTTだけでなく新聞の解約時にもサービス継続の勧誘を受けた。私の場合はどちらも断りすんなり済んだが、新規勧誘の煩わしさから、NTTよりも新聞の方がしつこいイメージがある。

    モデム返却については、転居先から返送したが、キーボードやブロードバンドルータなどの周辺機器と一緒に箱詰めすることになるので、転居先へ持っていくことについては特に問題だとは感じなかった。

    | | コメント (0) | トラックバック (0)

    «Holux m-241のログを編集するTRLログエディタ1.0a