JP5003278B2 - コンテンツデータファイル加工システム - Google Patents

Description

本発明は、コンテンツデータファイル加工システムに関する。

ＣＤ（Compact Disc）アルバムなどに記録された楽音信号をＭＰ３（MPEG-1 Audio Layer-3）やＷＭＡ（Windows（登録商標） Media Audio）などといったオーディオデータファイルに変換する機器の多くは、ＣＤに収録された各楽曲の曲名やアーティスト名などを示す楽曲メタデータをネットワーク上のデータベースから取得し、そのメタデータをＩＤ３ｖ２などの所定のフォーマットのタグデータとしてオーディオデータファイルへ埋め込むことができるようになっている（この仕組みについては、特許文献１を参照のこと）。

この種のメタデータを取り纏めたデータベースの１つに、ＣＤＤＢ(Compact Disc Data Base：商標)がある。例えば、グレースノート（商標）社の運営に係るＣＤＤＢは、各ＣＤに収録された楽曲の楽曲メタデータとそれらのＣＤのＴＯＣ（Table Of Contents）データとを対応付けている。ＴＯＣデータは、ＣＤに収録される各楽曲の各々の再生開始までの時間長を示すバイナリデータであり、ＰＣＭ（Pulse Code Modulation）オーディオデータを記録するプログラム領域の内側に確保されたリードイン領域に記録される。楽曲の各々の再生開始までの時間長の組み合わせは各アルバム毎に固有である。よって、ＣＤアルバムからＴＯＣデータを読み出した機器は、ＴＯＣデータを含むリクエストの送信と引き換えに、そのＣＤアルバムに収録された各楽曲の楽曲メタデータをＣＤＤＢから取得することができる。そして、それらの楽曲メタデータをＣＤアルバムから得たオーディオデータファイルへタグデータとしてそれぞれ埋め込んでおくと、後の再生時に参照したり、あるいは所望のオーディオデータファイルを検索するキーとして利用し得る。
特開２００５−１２２８６３

ところで、ＣＤＤＢなどのデータベースから提供される楽曲メタデータは、ＣＤアルバムに収録される各楽曲の、曲名、アーティスト名、ジャンルなどを示すものに限られる。よって、ＣＤアルバムから作成されるオーディオデータファイルの数が増えてくると、それらの全オーディオデータファイルの曲名やアーティスト名を正確に把握しておくことができず、曲名などをキーとして所望の楽曲を探し出すことは難しくなるという問題がある。

本発明は、このような背景の下に案出されたものであり、所望の楽曲の検索やソートをより効率的に行い得るようなオーディオデータファイルの加工を行う仕組みを提供することを目的とする。

本発明の好適な態様であるコンテンツデータファイル加工システムは、コンテンツデータを含む一または複数のコンテンツデータファイルを取得する第１の取得手段と、取得したコンテンツデータファイルに含まれるコンテンツデータの属性を示す属性データを取得する第２の取得手段と、複数のコンテンツデータの各集合体を示す集合体データとそれらの集合体をなす各コンテンツデータの属性を示す属性データとを各々対応付けて記憶した自装置のまたは外部のデータベースにおいて取得した属性データが複数の集合体データと対応付けられている場合に、プライオリティの高いデータであることを示すプライオリティデータを取得する第３の取得手段と、プライオリティデータを取得したコンテンツデータファイルに埋め込む埋込手段と、を備えることを特徴とする。

また、データベースから、取得した属性データを特定し、その属性データが複数の集合体データと対応付けられているか否か判断する判断手段をさらに備えてもよい。

また、埋込手段は、特定した属性データが複数の集合体データと対応付けられていると判断手段が判断したとき、その複数の集合体データの数に応じたプライオリティのランクを示すプライオリティデータを取得したコンテンツデータファイルに埋め込むようにしてもよい。

本発明の別の好適な態様であるコンテンツデータファイル加工システムは、コンテンツデータを含む一または複数のコンテンツデータファイルを取得する第１の取得手段と、取得したコンテンツデータファイルに含まれるコンテンツデータの属性を示す属性データを取得する第２の取得手段と、複数のコンテンツデータの各集合体を示す集合体データとそれらの集合体をなす各コンテンツデータの属性を示す属性データとを各々対応付けて記憶した自装置のまたは外部のデータベースに取得した属性データとの一致度が所定値以上である集合体データが記憶されている場合に、プライオリティの高いデータであることを示すプライオリティデータを取得する第３の取得手段と、プライオリティデータを取得したコンテンツデータファイルに埋め込む埋込手段とを備える。

また、データベースから、取得した属性データを特定し、その属性データをなすコード列との一致度が所定値以上である集合体データがデータベースに記憶されているか否か判断する判断手段をさらに備えてもよい。

本発明の別の好適な態様であるコンテンツデータファイル加工システムは、コンテンツデータを含む一又は複数のコンテンツデータファイルを取得する第１の取得手段と、取得したコンテンツデータファイルに含まれるコンテンツデータの属性を示す属性データを取得する第２の取得手段と、複数のコンテンツデータの集合体を示す集合体データ、集合体をなす各コンテンツデータの属性を示す属性データ、およびそれらのコンテンツデータの収録順を示す収録順データを各集合体ごとに対応付けて記憶した自装置のまたは外部のデータベースにおいて、取得した属性データとともに集合体データと対応付けられた属性データの数が所定の数よりも多く、且つ取得した属性データと対応付けられた収録順データが所定の条件を満たす場合に、プライオリティの高いコンテンツデータであることを示すプライオリティデータを取得する第３の取得手段と、プライオリティデータを取得したコンテンツデータファイルに埋め込む埋込手段とを備える。

また、データベースから、取得した属性データを特定し、その属性データとともに集合体データと対応付けられた属性データの数が所定の数よりも多いか否か判断する第１の判断手段と、属性データの数が所定の数よりも多いと第１の判断手段が判断したとき、取得した属性データと対応付けてデータベースに記憶された収録順データを基にコンテンツデータの収録順を特定し、特定した収録順が所定の条件を満たすか否か判断する第２の判断手段とをさらに備えてもよい。

また、コンテンツデータファイルは、オーディオデータを含むオーディオデータファイルであり、属性データは、オーディオデータとともに媒体に記録されているＴＯＣデータ、オーディオデータの波形を示す波形データ、オーディオデータの収録者を示すアーティスト名データ、オーディオデータファイルのファイル名を示すファイル名データ、およびオーディオデータが表す楽曲の名称を示す曲名データのいずれかまたは組み合わせであってもよい。

また、第１の取得手段は、媒体に記録されたオーディオデータ、または、そのオーディオデータを所定のデータ圧縮アルゴリズムに従って変換して得たオーディオデータを含むオーディオデータファイルを取得し、第２の取得手段は、オーディオデータとともに媒体に記録されたＴＯＣデータを属性データとして取得してもよい。

本発明によると、検索やソートをより効率的に行い得るようなオーディオデータファイルの加工を行うことができる。

（第１実施形態）
本発明の第１実施形態について、以下、図面を参照しながら説明する。

本発明の第１実施形態にかかるコンテンツデータファイル加工システムは、各ＣＤに収録されている楽曲の曲名、アーティスト名、ジャンルなどを示すデータ（以下、これらのデータを「楽曲メタデータ」と呼ぶ）とそれらのＣＤに記録されたＴＯＣデータとを対応付けたデータベースを有している。そして、ＣＤの各楽曲をリッピング（オーディオデータファイル化）する装置からのＴＯＣデータの発信と引き換えに、データベースから読み出したそのＣＤの各楽曲メタデータを配信し、各々のオーディオデータファイルへ埋め込ませるようになっている。このコンテンツデータ加工システムの特徴は、ＴＯＣデータにより特定されるＣＤの楽曲の中に別のＣＤにも収録されているものがあるとき、その楽曲のプライオリティが高いことを示すプライオリティデータを併せて埋め込ませるようにした点である。

図１は、本発明の第１実施形態にかかるコンテンツデータ加工システムを含むデータ配信システムの全体構成を示す図である。図１に示すように、このシステムは、楽曲メタデータ配信装置１０（「コンテンツデータファイル加工システム」の一部に相当）、オーディオ再生記録装置３０（「コンテンツデータファイル加工システム」の一部に相当）、パーソナルコンピュータ５０、モデム６１などを有する。オーディオ再生記録装置３０およびパーソナルコンピュータ５０は、ＬＡＮ（Local Area Network）ケーブル６０によりモデム６１と繋がれ、そのモデム６１からインターネット通信網６２を介して楽曲メタデータ配信装置１０と接続される。

図２は、楽曲メタデータ配信装置１０のハードウェア構成を示すブロック図である。図２に示すように、楽曲メタデータ配信装置１０は、ＣＰＵ１１（「判断手段」、「第１の判断手段」および「第２の判断手段」に相当）、ＲＡＭ１２、ＲＯＭ１３、ハードディスクドライブ１４、イーサネット（登録商標）コントローラ１５を有している。ＣＰＵ１１は、ＲＡＭ１２をワークエリアとして利用しつつ、ＲＯＭ１３やハードディスクドライブ１４に記憶された各種プログラムを実行する。ハードディスクドライブ１４には、ＣＤデータベース１６と楽曲メタデータ配信プログラム１７とが記憶される。

図３は、ＣＤデータベース１６のデータ構造図である。このＣＤデータベース１６は、各々が、各レーベルからリリースされているＣＤと対応する複数のレコードの集合体である。それらのＣＤは、１曲から４曲程度の楽曲が収録されたシングルＣＤと、それ以上の楽曲が収録されたアルバムＣＤの双方を含む。このデータベース１６を構成する各レコードは、「ＴＯＣ」、「タイトル」、「トラック」、「曲名」、「アーティスト」の５つのフィールドを有している。そして、１つのＣＤと対応するレコードの「トラック」、「曲名」、「アーティスト」のフィールドは、そのＣＤに収録された楽曲と同じ数に分かれている。

「ＴＯＣ」のフィールドには、各ＣＤのＴＯＣデータが記憶される。ＴＯＣデータは、ＣＤに収録される各楽曲の再生開始までの時間長を示すバイナリデータであり、ＣＤのリードイン領域に記録される。ＣＤに収録される楽曲の各々の再生開始までの時間長の組み合わせは固有であるため、このＴＯＣデータをキーとして検索を行うことにより、対応する唯一のＣＤのレコードを特定することが可能である。「タイトル」のフィールドには、ＣＤのタイトルを示すタイトルデータ（「集合体データ」に相当）が記憶される。

「トラック」、「曲名」、「アーティスト」のフィールドには、楽曲メタデータをなす、トラックデータ、曲名データ、およびアーティスト名データがそれぞれ記憶される。トラックデータ（「収録順データ」に相当）は、ＣＤに収録された各楽曲のトラック番号を示すデータである。また、曲名データは、ＣＤに収録された各楽曲の曲名を示すデータであり、アーティスト名データは、それらの各楽曲の収録にかかわった一又は複数のアーティストの名称を示すデータである。

図２において、楽曲メタデータ配信プログラム１７は、ＴＯＣデータを含むリクエストをオーディオ再生記録装置３０から受信し、リクエストに含まれるＴＯＣデータをキーとして検索して特定された楽曲メタデータをその発信元へ配信するプログラムである。

図４は、オーディオ再生記録装置３０のハードウェア構成を示す図である。図４に示すように、オーディオ再生記録装置３０は、ＡＤＣ（Analog Digital Converter）３１、ＤＡＣ（Digital Analog Converter）３２、ＤＳＰ（Digital Signal Processor）３３、チューナ３４、イーサネット（登録商標）コントローラ３５、ＵＳＢ（Universal Serial Bus）コントローラ３６、操作部３７、表示部３８、ＣＤドライブ３９、ＣＰＵ（Central Processing Unit：「第１の取得手段」、「第２の取得手段」、「第３の取得手段」、「埋込手段」に相当）４０、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）４１、フラッシュメモリ４２、ＳＤＲＡＭ（Double Data Rate Synchronous Dynamic Random Access Memory) ４３、ハードディスクドライブ４４を有する。

ＡＤＣ３１は、マイクロホンなどの収音機器（図示せず）と接続され、それらの機器から供給されるアナログ信号をデジタル信号に変換する。ＡＤＣ３１にて変換された信号は、ＤＳＰ３３を経由してＣＰＵ４０へ供給される。ＤＡＣ３２は、スピーカやヘッドフォンなどの放音機器（図示せず）と接続され、ＣＰＵ４０からＤＡＣ３２を経由して供給されるデジタル信号をアナログ信号に変換する。ＤＡＣ３２にて変換された信号は、放音機器へ供給される。ＤＳＰ３３は、ＣＰＵ４０による制御の下、自らを経由するデジタル信号へ信号処理を施す。

チューナ３４は、ＣＰＵ４０による制御の下、アンテナ４５により受信される搬送波を復調して得た信号をＣＰＵ４０に供給し、そのアンテナの最大感度の周波数を特定の放送局の周波数へ同調させるなどといった処理を行う。

イーサネット（登録商標）コントローラ３５は、モデム６１やパーソナルコンピュータ５０とＬＡＮケーブル６０を介して接続され、所定のプロトコルに従ってそれらの装置との間でデータの送受信を行う。ＵＳＢコントローラ３６は、ポータブルメモリプレーヤなどの各種音楽再生端末（図示せず）とＵＳＢケーブル（図示せず）を介して接続され、所定のプロトコルに従ってそれらの端末との間でデータの送受信を行う。

操作部３７は、タッチパネルやつまみなどの操作子を有し、それらの操作子による操作を示す信号をＣＰＵ４０へ供給する。表示部３８は、例えば、液晶ディスプレイを有し、ＣＰＵ４０から供給される信号を基にそのディスプレイへ各種情報を表示させる。

ＣＤドライブ３９は、ＣＤ載置トレイ、光学ヘッド、デコーダなどを有する。このＣＤドライブ３９は、ＣＰＵ４０による制御の下、ＣＤのプログラム領域から読み取ったＰＣＭ（Pulse Code Modulation）オーディオデータの信号、およびそのリードイン領域から読み取ったＴＯＣデータの信号をＣＰＵ４０へ供給する。

ＣＰＵ４０は、ＳＤＲＡＭ４３をワークエリアとして利用しつつ、ＥＥＰＲＯＭ４１、フラッシュメモリ４２、ハードディスクドライブ４４に記憶された各種プログラムを実行する。それらのプログラムを実行するＣＰＵ４０は、ＣＤドライブ３９やチューナ３４から供給されるデジタル信号をＤＡＣ３２を介して放音機器へ供給して放音させたり、そのデジタル信号から得たオーディオデータファイルをハードディスクドライブ４４に記憶させたりといった処理を行う、また、ハードディスクドライブ４４に記憶させたオーディオデータファイルを、イーサネット（登録商標）コントローラ３５やＵＳＢコントローラ３６から、外部の端末やパーソナルコンピュータ５０へ伝送させるなどといった処理も行う。

パーソナルコンピュータ５０は、オーディオ再生記録装置３０を操作するためのコマンドを自らのイーサネット（登録商標）コントローラ（図示せず）からオーディオ再生記録装置３０へ供給したり、また、オーディオ再生記録装置３０がＣＤから生成したオーディオデータファイルを取得し、再生する。パーソナルコンピュータ５０のハードウェア構成は、ハードディスクドライブの記憶内容を除いて図２に示した楽曲メタデータ配信装置１０と同様である。ただし、パーソナルコンピュータ５０に、オーディオ再生記録装置３０のハードウェア構成を持たせ、上述のオーディオ再生記録装置３０と同様の処理を行うようにしてもよい。

次に、本実施形態の動作を説明する。図５および図６は、本実施形態の特徴的な処理を示すフローチャートである。このフローチャートに示す一連の処理は、オーディオ再生記録装置３０のＣＤドライブ３９にＣＤが装填された状態で、操作部３７の操作を通じてオーディオデータファイルの生成の指示が下されると開始される。

オーディオデータファイルの生成の指示が下されると、オーディオ再生記録装置３０のＣＰＵ４０は、ＣＤドライブ３９に装填されたＣＤのプログラム領域から読み出された各楽曲のＰＣＭオーディオデータを取得するとともに（Ｓ１００）、そのリードイン領域から読み出した各楽曲のＴＯＣデータ（「属性データ」に相当）を取得する（Ｓ１１０）。

続いて、ＣＰＵ４０は、ステップＳ１１０で取得したＴＯＣデータを含むＨＴＴＰ（Hypertext Transfer Protocol）リクエストをイーサネット（登録商標）コントローラ３５から楽曲メタデータ配信装置１０に宛てて送信させた後（Ｓ１２０）、ステップＳ１００で取得したＰＣＭオーディオデータを圧縮して得たオーディオデータとステップＳ１１０で取得したＴＯＣデータとを含む各楽曲毎のオーディオデータファイルを取得する（Ｓ１３０）。

ここで、ステップＳ１３０におけるＰＣＭオーディオデータの圧縮は、ＭＰ３やＷＡＶのデータ圧縮アルゴリズムに従って行われることが望ましい。その場合、ステップＳ１３０で取得される各オーディオデータファイルの拡張子は、MP3やWAVとなる。また、各々のファイル名は、「Track 1」や「Track 2」などといった、ＣＤへの収録順を示す文字列となる。また、ステップＳ１３０で取得されたオーディオデータファイルは、ＳＤＲＡＭ４３に記憶される。送信されたリクエストは、モデム６１、およびインターネット通信網６２をなす一または複数のノードを経由して、楽曲メタデータ配信装置１０へ送信される。

ＨＴＴＰリクエストを受信した楽曲メタデータ配信装置１０のＣＰＵ１１は、受信したリクエストに含まれるＴＯＣデータをＲＡＭ１２に記憶した後、そのＴＯＣデータを「ＴＯＣ」のフィールドに記憶したレコードがＣＤデータベース１６にあるか否か判断する（Ｓ１４０）。ステップＳ１４０にて、ＴＯＣデータを記憶したレコードがないと判断したとき（Ｓ１４０：Ｎｏ）、ＣＰＵ１１は、そのことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元に宛てて送信する（Ｓ１５０）。ＴＯＣデータを記憶したレコードがないことを示すメッセージを含むＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ４０は、楽曲メタデータが存在しないことを示す文字列を表示部３８に表示させた後（Ｓ１６０）、処理を終了する。

ステップＳ１４０にて、ＴＯＣデータを記憶したレコードがあると判断したとき（Ｓ１４０：Ｙｅｓ）、ＣＰＵ１１は、そのレコードの「トラック」、「曲名」、「アーティスト」などのフィールドに記憶されたデータの纏まりである楽曲メタデータを、各楽曲ごとに読み出す（Ｓ１７０）。例えば、ＣＤに１０の楽曲が収録されている場合、本ステップＳ１７０では、それらの１０の楽曲の各々と対応する楽曲メタデータがＣＤデータベース１６から読み出される。

ＣＰＵ１１は、ステップＳ１７０で読み出した楽曲メタデータを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ１８０）。送信されたレスポンスは、インターネット通信網６２の一又は複数のノードおよびモデム６１を経由して、オーディオ再生記録装置３０へ送信される。

ＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ４０は、受信したレスポンスに含まれる各楽曲メタデータを、ステップＳ１３０で取得したオーディオデータファイルの各々へ、タグデータとして埋め込む（Ｓ１９０）。ＭＰ３などのオーディオデータファイルに埋め込み得るタグデータのデータ形式としては、ID3v1（ID3 Tag Version 1）やID3v2（ID3 Tag Version 2）などがある。よって、ステップＳ１９０では、各楽曲メタデータをこれらのデータ形式に変換した上でオーディオデータへ埋め込むとよい。オーディオデータファイルのファイル名はＣＤへの収録順を示す文字列である一方、楽曲メタデータの一部をなすトラックデータは、ＣＤに収録された各楽曲のトラック番号を示すデータである。よって、そのトラックデータと各オーディオデータのファイル名とを基に両者の対応付けを行うとよい。

ＣＰＵ４０は、ステップＳ１９０にてタグデータを埋め込んだ各オーディオデータファイルのうち、最初の楽曲のオーディオデータファイル、つまり、最初のトラックのトラックデータを埋め込んだオーディオデータファイルを特定する（Ｓ２００）。

続いて、ＣＰＵ４０は、ステップＳ２００で特定したオーディオデータファイルにタグデータとして埋め込まれている曲名データを取得し、その曲名データを含むＨＴＴＰリクエストをイーサネット（登録商標）コントローラ３５から楽曲メタデータ配信装置１０に宛てて送信させる（Ｓ２１０）。送信されたリクエストは、モデム６１、およびインターネット通信網６２をなす一または複数のノードを経由して、楽曲メタデータ配信装置１０へ送信される。

ＨＴＴＰリクエストを受信した楽曲メタデータ配信装置１０のＣＰＵ１１は、受信したリクエストに含まれる曲名データが、ステップＳ１７０にて楽曲メタデータを読み出したレコードと別のレコードに記憶されているか否か判断する（Ｓ２２０）。曲名データにより特定される楽曲が人気のある楽曲で複数のＣＤに収録されている場合、ステップＳ２２０の判断結果は「Ｙｅｓ」となり、そうでない場合、ステップＳ２２０の判断結果は「Ｎｏ」となる。

ステップＳ２２０にて、リクエストに含まれる曲名データが別のレコードに記憶されていると判断されたとき（Ｓ２２０：Ｙｅｓ）、ＣＰＵ１１は、曲名データを記憶した別のレコードがあることを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ２３０）。一方、ステップＳ２２０にて、リクエストに含まれる曲名データが別のレコードに含まれていないと判断したとき（Ｓ２２０：Ｎｏ）、ＣＰＵ１１は、曲名データを記憶した別のレコードがないことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ２４０）。送信されたレスポンスは、インターネット通信網６２の一又は複数のノードおよびモデム６１を経由して、オーディオ再生記録装置３０へ送信される。

ＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ４０は、そのレスポンスに含まれるメッセージが、曲名データを記憶した別のレコードがあることを示すものであるか、そのようなレコードがないことを示すものであるかを判断する（Ｓ２５０）。ステップＳ２５０にて、曲名データを記憶した別のレコードがあることを示すメッセージであると判断したとき（Ｓ２５０：Ｙｅｓ）、ＣＰＵ４０は、プライオリティデータをステップＳ２００で特定したオーディオデータファイルへタグデータとして埋め込む（Ｓ２６０）。プライオリティデータは、楽曲の優先度が高いことを示すデータである。一方、ステップＳ２５０にて、曲名データを記憶した別のレコードがないことを示すメッセージであると判断したとき（Ｓ２５０：Ｎｏ）、ＣＰＵ４０は、ステップＳ２６０を実行することなく次のステップへ進む。

ＣＰＵ４０は、ステップＳ１９０にて楽曲メタデータを埋め込んだ各オーディオデータファイルのうち、ステップＳ２００で特定したオーディオデータファイルの次の楽曲のオーディオデータファイルがあるか否か判断する（Ｓ２７０）。ステップＳ２７０にて、次のオーディオデータファイルがあると判断したとき（Ｓ２７０：Ｙｅｓ）、ＣＰＵ４０は、そのオーディオデータファイルを特定した後（Ｓ２８０）、特定したオーディオデータファイルを対象としてステップＳ２１０以降の処理を実行する。一方、ステップＳ２７０にて、次のオーディオデータファイルがないと判断したとき（Ｓ２７０：Ｎｏ）、ＣＰＵ４０は、ＣＤのリッピングが終了したことを示す文字列を表示部３８に表示させた後（Ｓ２９０）、処理を終了する。上述した一連のステップにより得られたオーディオデータファイルは、ハードディスクドライブ４４に記憶され、オーディオデータファイル再生アプリケーションにより再生される。

以上説明した本実施形態では、オーディオ再生記録装置３０のＣＤドライブ３９に装填されたＣＤの各楽曲をリッピングしてオーディオデータファイルを生成する際、それらの楽曲の各々が別のＣＤにも収録されているか否かを判断する。そして、別のＣＤに収録されている楽曲については、優先度の高い楽曲であることを示すプライオリティデータがそのオーディオデータファイルへタグデータとして埋め込まれる。埋め込まれたプライオリティデータは、曲名やアーティスト名のタグデータと同様に、オーディオデータファイル再生アプリケーションによって参照可能である。よって、このプライオリティデータを参照することにより、複数のＣＤに収録されているような人気の楽曲を、ハードディスクドライブ４４に記憶された複数のオーディオデータファイルの中から容易に検索することが可能となる。また、曲名やアーティスト名をキーとして検索した複数のオーディオデータファイルを、複数のＣＤに収録されている人気曲から順にソートして表示させることも可能となる。

（第２実施形態）
本発明の第２実施形態について、以下、図面を参照しながら説明する。

第１実施形態では、ＣＤ一枚に収録される全ての楽曲のリッピング、およびそのリッピングにより得たオーディオデータファイルの全部又は一部へのプライオリティデータの埋め込みが連続して行われるようになっている。これに対し、本実施形態では、ＣＤのリッピングとプライオリティデータの埋め込みを別の手続きとして行い、オーディオ再生記録装置３０のハードディスクドライブ４４に記憶された一又は複数のオーディオデータファイルの中から選択されたオーディオデータファイルごとに、プライオリティデータの埋め込みの有無を判断する。

本実施形態にかかるデータ配信システムをなす、楽曲メタデータ配信装置１０、オーディオ再生記録装置３０、パーソナルコンピュータ５０、およびモデム６１のハードウェア構成は第１実施形態と同様であり、再度の説明を割愛する。

次に、本実施形態の動作を説明する。図７は、本実施形態の特徴的な処理を示すフローチャートである。このフローチャートに示す一連の処理は、一又は複数のオーディオデータファイルがハードディスクドライブ４４に記憶された状態で、操作部３７の操作を通じてそれらのいずれかが選択されると開始される。なお、選択の対象となり得るオーディオデータファイルは、他のオーディオ再生記録装置３０やパーソナルコンピュータ５０から伝送されたり、または、ネットワーク経由でダウンロードしたオーディオデータファイルであり、且つその後の操作部３７からの操作や楽曲メタデータ配信装置１０へのアクセスを通じて曲名とアーティスト名のタグデータが埋め込まれたオーディオデータファイルである。

オーディオデータファイルが選択されると、ＣＰＵ４０は、そのオーディオデータファイルにタグデータとして埋め込まれている曲名とアーティスト名とを取得した後（Ｓ３００）、取得した曲名を示す曲名データ（「属性データ」の一部に相当）とアーティスト名を示すアーティスト名データ（「属性データ」の一部に相当）とを含むＨＴＴＰリクエストをイーサネット（登録商標）コントローラ３５から楽曲メタデータ配信装置１０に宛てて送信させる（Ｓ３１０）。

ＨＴＴＰリクエストを受信した楽曲メタデータ配信装置１０のＣＰＵ１１は、受信したリクエストに含まれる曲名データを「曲名」のフィールドに記憶し、そのリクエストに含まれるアーティスト名データを「アーティスト」のフィールドに記憶したレコードがＣＤデータベース１６にあるか否か判断する（Ｓ３２０）。つまり、本ステップＳ３２０では、曲名とアーティスト名の組み合わせをキーとして検索が行われる。

ステップＳ３２０にて、曲名データおよびアーティスト名データを記憶したレコードがないと判断したとき（Ｓ３２０：Ｎｏ）、ＣＰＵ１１は、そのことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元に宛てて送信する（Ｓ３３０）。曲名データおよびアーティスト名データを記憶したレコードがないことを示すメッセージを含むＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ４０は、楽曲メタデータが存在しないことを示す文字列を表示部３８に表示させた後（Ｓ３４０）、処理を終了する。

ステップＳ３２０にて、曲名データおよびアーティスト名データを記憶したレコードがあると判断したとき（Ｓ３２０：Ｙｅｓ）、ＣＰＵ１１は、そのレコードの「曲名」のフィールドに記憶された曲名データが、別のレコードの「曲名」のフィールドにも記憶されているか否か判断する（Ｓ３５０）。曲名データにより特定される楽曲が人気のある楽曲で複数のＣＤに収録されている場合、ステップＳ３５０の判断結果は「Ｙｅｓ」となり、そうでない場合、ステップＳ３５０の判断結果は「Ｎｏ」となる。

ステップＳ３５０にて、リクエストに含まれる曲名データが別のレコードに記憶されていると判断したとき（Ｓ３５０：Ｙｅｓ）、ＣＰＵ１１は、曲名データを記憶した別のレコードがあることを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ３６０）。一方、ステップＳ３５０にて、リクエストに含まれる曲名データが別のレコードに記憶されていないと判断したとき（Ｓ３５０：Ｎｏ）、ＣＰＵ１１は、曲名データを記憶した別のレコードがないことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ３７０）。

ＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ４０は、そのレスポンスに含まれるメッセージが、曲名データを記憶した別のレコードがあることを示すものであるか、そのようなレコードがないことを示すものであるかを判断する（Ｓ３８０）。ステップＳ３８０にて、曲名データを記憶した別のレコードがあることを示すメッセージであると判断したとき（Ｓ３８０：Ｙｅｓ）、ＣＰＵ４０は、オーディオデータファイルへプライオリティデータをタグデータとして埋め込んだ後（Ｓ３９０）、処理を終了する。一方、ステップＳ３８０にて、曲名データを記憶した別のレコードがないことを示すメッセージであると判断したとき（Ｓ３８０：Ｎｏ）、ＣＰＵ４０は、ステップＳ３９０を実行することなく、処理を終了する。

以上説明した本実施形態では、オーディオデータファイルへのプライオリティデータの埋め込みが、ＣＤのリッピングによるそのオーディオデータファイルの生成とは別の手続きとして行われる。また、ＴＯＣデータの代わりに、オーディオデータファイルにタグデータとして埋め込まれている曲名とアーティスト名とをキーとしてＣＤデータベース１６の検索が行われる。よって、他のオーディオ再生記録装置３０やパーソナルコンピュータ５０から伝送されたり、または、ネットワーク経由でダウンロードしたオーディオデータファイルのようにその収録元のＣＤからＴＯＣデータを取得しえないものについても、プライオリティデータの埋め込みの有無の判断を行うことができる。

（第３実施形態）
本発明の第３実施形態について、以下、図面を参照しながら説明する。

第２実施形態では、オーディオデータファイルの楽曲の曲名とアーティスト名とをキーとしてＣＤデータベース１６を検索し、参照するレコードを特定するようになっている。これに対し、本実施形態では、他のオーディオ再生記録装置３０やパーソナルコンピュータ５０から伝送されたり、または、ネットワーク経由でダウンロードしたオーディオデータファイルのファイル名が、その楽曲名に変更された上でハードディスクドライブ４４に記憶されることが多いことから、オーディオデータファイルのファイル名を曲名のキーとみなしてＣＤデータベース１６の検索を行う。

本実施形態にかかるデータ配信システムをなす、楽曲メタデータ配信装置１０、オーディオ再生記録装置３０、パーソナルコンピュータ５０、およびモデム６１のハードウェア構成は上記両実施形態と同様であり、再度の説明を割愛する。

次に、本実施形態の動作を説明する。図８および図９は、本実施形態の特徴的な処理を示すフローチャートである。このフローチャートに示す一連の処理は、一又は複数のオーディオデータファイルがハードディスクドライブ４４に記憶された状態で、操作部３７の操作を通じてそれらのいずれかが選択されると開始される。なお、選択の対象となり得るオーディオデータファイルは、他のオーディオ再生記録装置３０やパーソナルコンピュータ５０から伝送されたり、または、ネットワーク経由でダウンロードしたオーディオデータファイルであり、且つ操作部３７からの操作によってそのファイル名が楽曲の曲名に変更されたオーディオデータファイルである。ただし、第２実施形態と異なり、それらのオーディオデータファイルに曲名やアーティスト名がタグデータとして埋め込まれている必要はない。

オーディオデータファイルが選択されると、ＣＰＵ４０は、そのオーディオデータファイルのファイル名を示す文字列を取得した後（Ｓ４００）、取得した文字列を示すファイル名データ（「属性データ」に相当）を含むＨＴＴＰリクエストをイーサネット（登録商標）コントローラ３５から楽曲メタデータ配信装置１０に宛てて送信させる（Ｓ４１０）。

ＨＴＴＰリクエストを受信した楽曲メタデータ配信装置１０のＣＰＵ１１は、受信したリクエストに含まれるファイル名データと同じ文字列からなる曲名データを「曲名」のフィールドに記憶したレコードが、ＣＤデータベース１６にあるか否か判断する（Ｓ４２０）。つまり、本ステップＳ４２０では、ファイル名データが示す文字列が曲名と同じであるとみなし、その文字列をキーとして検索が行われる。

ステップＳ４２０にて、ファイル名データと同じ文字列の曲名データを記憶したレコードがないと判断したとき（Ｓ４２０：Ｎｏ）、ＣＰＵ１１は、そのことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元に宛てて送信する（Ｓ４３０）。ファイル名データと同じ文字列の曲名データを記憶したレコードがないことを示すメッセージを含むＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ１１は、楽曲メタデータが存在しないことを示す文字列を表示部３８に表示させた後（Ｓ４４０）、処理を終了する。

ステップＳ４２０にて、ファイル名データと同じ文字列の曲名データを記憶したレコードがあると判断したとき（Ｓ４２０：Ｙｅｓ）、ＣＰＵ１１は、そのレコードの「曲名」のフィールドに記憶された曲名データが、「アーティスト」のフィールドの記憶内容を異にする複数のレコードに記憶されているか否か判断する（Ｓ４５０）。つまり、このステップＳ４５０では、同じ曲名の楽曲が、別々のアーティストが収録にかかわったＣＤの収録曲になっているか否かが判断される。

ステップＳ４５０にて、「アーティスト」のフィールドの記憶内容を異にする複数のレコードに曲名データが記憶されていると判断したとき（Ｓ４５０：Ｙｅｓ）、ＣＰＵ１１は、それらの複数のレコードの「アーティスト」のフィールドに記憶されたアーティスト名データを読み出し、それらのアーティスト名データを含むＨＴＴＰレスポンスをリクエストの発信元に宛てて送信する（Ｓ４６０）。

ＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ４０は、そのレスポンスに含まれる複数のアーティスト名データを基にレイアウトしたアーティスト選択画面を表示部３８に表示させる（Ｓ４７０）。アーティスト選択画面は、「アーティストを選択してください」という文字列と、複数のアーティスト名を示す文字列とを並べた画面である。この画面を参照したユーザは、操作部３７の操作を通じ、いずれかのアーティスト名を選択する。

アーティスト名が選択されると（Ｓ４８０：Ｙｅｓ）、ＣＰＵ４０は、その選択されたアーティスト名のアーティスト名データを含むＨＴＴＰリクエストをイーサネット（登録商標）コントローラ３５から楽曲メタデータ配信装置１０に宛てて送信させる（Ｓ４９０）。

ＨＴＴＰリクエストを受信した楽曲メタデータ配信装置１０のＣＰＵ１１は、そのリクエストに含まれるアーティスト名データを「アーティスト」のフィールドに記憶し、且つステップＳ４２０の判断に用いたファイル名データと同じ文字列の曲名データを「曲名」のフィールドに記憶した複数のレコードがあるか否か判断する（Ｓ５００）。つまり、このステップＳ５００では、オーディオデータファイルのファイル名により特定され且つユーザの選択にかかるアーティストの楽曲が複数のＣＤに収録されているか、それとも、そのようなＣＤは一枚であるかが判断される。なお、ステップＳ４５０にて、「アーティスト」のフィールドの記憶内容を異にする複数のレコードに曲名データが記憶されていないと判断したとき、ステップＳ４６０からステップＳ４９０が実行されることなく、ステップＳ５００へ進む。

ステップＳ５００にて、同じ文字列の曲名データを記憶した複数のレコードがあると判断したとき（Ｓ５００：Ｙｅｓ）、ＣＰＵ１１は、そのことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ５１０）。一方、ステップＳ５００にて、同じ文字列の曲名データを記憶した複数のレコードがないと判断したとき（Ｓ５００：Ｎｏ）、ＣＰＵ１１は、そのことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ５２０）。ＨＴＴＰレスポンスを受信した楽曲メタデータ配信装置１０は、図７のステップＳ３８０およびステップＳ３９０と同様の処理を行う（Ｓ５３０およびＳ５４０）。

以上説明した本実施形態では、オーディオデータファイルのファイル名の文字列がその曲名と同じであるとみなし、ファイル名をキーとしてＣＤデータベース１６の検索を行うようになっている。よって、操作部３７からの操作や楽曲メタデータ配信装置１０へのアクセスを通じて曲名やアーティスト名のタグデータが埋め込まれていないオーディオデータファイルであっても、プライオリティデータの埋め込みの有無を判断することができる。

（第４実施形態）
本発明の第４実施形態について、以下、図面を参照しながら説明する。

第２実施形態では、あるオーディオデータファイルの楽曲の曲名およびアーティスト名をキーとしてＣＤデータベース１６から特定したレコードと「曲名」のフィールドの記憶内容を同じくする別のレコードがあるとき、プライオリティデータをそのオーディオデータファイルへ埋め込むようになっている。これに対し、本実施形態では、人気のある楽曲の曲名はＣＤそのもののタイトルになっていることが多いことから、あるオーディオデータファイルの楽曲の曲名と「タイトル」のフィールドの記憶内容を同じくする別のレコードがあるとき、プライオリティデータをそのオーディオデータファイルへ埋め込む。

本実施形態にかかるデータ配信システムをなす、楽曲メタデータ配信装置１０、オーディオ再生記録装置３０、パーソナルコンピュータ５０、およびモデム６１のハードウェア構成は上記の３つの実施形態と同様であり、再度の説明を割愛する。

次に、本実施形態の動作を説明する。図１０は、本実施形態の特徴的な処理を示すフローチャートである。このフローチャートに示す一連の処理は、一又は複数のオーディオデータファイルがハードディスクドライブ４４に記憶された状態で、操作部３７の操作を通じてそれらのいずれかが選択されると開始される。なお、選択の対象となり得るオーディオデータファイルは、他のオーディオ再生記録装置３０やパーソナルコンピュータ５０から伝送されたり、または、ネットワーク経由でダウンロードしたオーディオデータファイルであり、且つその後の操作部３７からの操作や楽曲メタデータ配信装置１０へのアクセスを通じて曲名とアーティスト名のタグデータが埋め込まれたオーディオデータファイルである。

オーディオデータファイルが選択されると、ＣＰＵ４０は、そのオーディオデータファイルにタグデータとして埋め込まれている曲名とアーティスト名とを取得した後（Ｓ６００）、取得した曲名を示す曲名データ（「属性データ」の一部に相当）とアーティスト名を示すアーティスト名データ（「属性データ」の一部に相当）とを含むＨＴＴＰリクエストをイーサネット（登録商標）コントローラ３５から楽曲メタデータ配信装置１０に宛てて送信させる（Ｓ６１０）。

ＨＴＴＰリクエストを受信した楽曲メタデータ配信装置１０のＣＰＵ１１は、受信したリクエストに含まれる曲名データを「曲名」のフィールドに記憶し、そのリクエストに含まれるアーティスト名データを「アーティスト」のフィールドに記憶したレコードがＣＤデータベース１６にあるか否か判断する（Ｓ６２０）。

ステップＳ６２０にて、曲名データおよびアーティスト名データを記憶したレコードがないと判断したとき（Ｓ６２０：Ｎｏ）、ＣＰＵ１１は、そのことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元に宛てて送信する（Ｓ６３０）。曲名データおよびアーティスト名データを記憶したレコードがないことを示すメッセージを含むＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ４０は、楽曲メタデータが存在しないことを示す文字列を表示部３８に表示させた後（Ｓ６４０）、処理を終了する。

ステップＳ６２０にて、曲名データおよびアーティスト名データを記憶したレコードがあると判断したとき（Ｓ６２０：Ｙｅｓ）、ＣＰＵ１１は、そのレコードの「曲名」のフィールドに記憶された曲名データと同じ文字列からなるタイトルデータが、同じレコードまたは別のレコードの「タイトル」のフィールドに記憶されているか否か判断する（Ｓ６５０）。曲名データにより特定される楽曲が人気のある楽曲でその曲名がＣＤそのもののタイトルになっている場合、ステップＳ６５０の判断結果は「Ｙｅｓ」となり、そうでない場合、ステップＳ６５０の判断結果は「Ｎｏ」となる。

ステップＳ６５０にて、曲名データと同じ文字列からなるタイトルデータが、同じレコードまたは別のレコードの「タイトル」のフィールドに記憶されていると判断したとき（Ｓ６５０：Ｙｅｓ）、ＣＰＵ１１は、曲名データと同じ文字列のタイトルデータを記憶したレコードがあることを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ６６０）。一方、ステップＳ６５０にて、リクエストに含まれる曲名データが同じまたは別のレコードに含まれていないと判断したとき（Ｓ６５０：Ｎｏ）、ＣＰＵ１１は、曲名データと同じ文字列のタイトルデータを記憶したレコードがないことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ６７０）。ＨＴＴＰレスポンスを受信した楽曲メタデータ配信装置１０は、そのレスポンスに含まれるメッセージが、曲名データと同じ文字列のタイトルデータを記憶したレコードがあることを示すものであるか、そのようなレコードがないことを示すものであるかを判断し（Ｓ６８０）、その判断の結果を基に図７のステップＳ３９０と同様の処理を行う（Ｓ６９０）。

以上説明した本実施形態によると、オーディオデータファイルの楽曲の曲名とその楽曲を収録したＣＤ、または別のＣＤのタイトル名とが一致するか否かの判断に基づいて、プライオリティデータの埋め込みの有無の判断を行うようになっている。このような手順によっても、プライオリティデータを埋め込むのに相応しい楽曲を高確度に特定することができる。

（第５実施形態）
本発明の第５実施形態について、以下、図面を参照しながら説明する。

第２実施形態では、あるオーディオデータファイルの楽曲の曲名およびアーティスト名をキーとしてＣＤデータベース１６から特定したレコードと「曲名」のフィールドの記憶内容を同じくする別のレコードがあるとき、プライオリティデータをそのオーディオデータファイルへ埋め込むようになっている。これに対し、本実施形態では、収録曲が１曲から４曲程度のシングルＣＤの最初に収録された楽曲は人気が高いものであることが多いことから、あるオーディオデータファイルの楽曲の曲名およびアーティスト名をキーとしてＣＤデータベース１６から特定したレコードに記憶されたトラックデータの数が４つ以下であり、且つそのオーディオデータファイルのトラックデータが「Track 1」を示すものであるとき、プライオリティデータをそのオーディオデータファイルへ埋め込む。

本実施形態にかかるデータ配信システムをなす、楽曲メタデータ配信装置１０、オーディオ再生記録装置３０、パーソナルコンピュータ５０、およびモデム６１のハードウェア構成は上記の４つの実施形態と同様であり、再度の説明を割愛する。

次に、本実施形態の動作を説明する。図１１は、本実施形態の特徴的な処理を示すフローチャートである。このフローチャートに示す一連の処理は、一又は複数のオーディオデータファイルがハードディスクドライブ４４に記憶された状態で、操作部３７の操作を通じてそれらのいずれかが選択されると開始される。なお、選択の対象となり得るオーディオデータファイルは、他のオーディオ再生記録装置３０やパーソナルコンピュータ５０から伝送されたり、または、ネットワーク経由でダウンロードしたオーディオデータファイルであり、且つその後の操作部３７からの操作や楽曲メタデータ配信装置１０へのアクセスを通じて曲名とアーティスト名のタグデータが埋め込まれたオーディオデータファイルである。

オーディオデータファイルが選択されると、図７のステップＳ３００からステップＳ３２０と同様の処理が実行され（Ｓ７００からＳ７２０）、ステップＳ７２０にて、リクエストに含まれる曲名データ（「属性データ」の一部に相当）およびアーティスト名データ（「属性データ」の一部に相当）を記憶したレコードがＣＤデータベース１６にないとＣＰＵ１１が判断すると（Ｓ７２０：Ｎｏ）、図７のステップＳ３３０からステップＳ３４０と同様の処理が実行される（Ｓ７３０からＳ７４０）。

ステップＳ７２０にて、リクエストに含まれる曲名データおよびアーティスト名データを記憶したレコードがＣＤデータベース１６にあると判断すると（Ｓ７２０：Ｙｅｓ）、ＣＰＵ１１は、そのレコードの「トラック」のフィールドに記憶されたトラックデータの数が４つ以下であるか否か判断する（Ｓ７５０）。曲名データにより特定される楽曲がシングルＣＤに収録されている場合、ステップＳ７５０の判断結果は「Ｙｅｓ」となり、そうでない場合、ステップＳ７５０の判断結果は「Ｎｏ」となる。

ステップＳ７５０にて、「トラック」のフィールドに記憶されたトラックデータの数が４つ以下であると判断したとき（Ｓ７５０：Ｙｅｓ）、ＣＰＵ１１は、リクエストに含まれる曲名データと対応するトラックデータが「Track 1」を示すものであるか否か判断する（Ｓ７５１）。つまり、本ステップＳ７５１では、曲名データによって特定される楽曲が、シングルＣＤの最初に収録されているか否かが判断される。

ステップＳ７５１にて、リクエストに含まれる曲名データと対応するトラックデータが「Track 1」を示すものであると判断したとき（Ｓ７５１：Ｙｅｓ）、ＣＰＵ１１は、曲名データと対応するトラックデータが、４つ以上あるうちの「Track 1」であることを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ７６０）。一方、ステップＳ７５０にて、「トラック」のフィールドに記憶されたトラックデータの数が４つよりも多いと判断したとき（Ｓ７５０：Ｎｏ）、または、ステップＳ７５１にて、リクエストに含まれる曲名データと対応するトラックデータが「Track 1」を示すものでないと判断したとき（Ｓ７５１：Ｎｏ）、ＣＰＵ１１は、曲名データと対応するトラックデータが、４つ以上あるうちの「Track 1」でないことを示すメッセージを含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ７７０）。ＨＴＴＰレスポンスを受信した楽曲メタデータ配信装置１０は、そのレスポンスに含まれるメッセージが、４つ以上あるうちの「Track 1」であることを示すものであるかを判断し（Ｓ７８０）、その判断の結果を基に図７のステップＳ３９０と同様の処理を行う（Ｓ７９０）。

以上説明した本実施形態では、あるオーディオデータファイルの楽曲の曲名およびアーティスト名をキーとしてＣＤデータベース１６から特定したレコードの「トラック」のフィールドに記憶されたトラックデータの数が４つ以下であるかを判断したあと、そのオーディーデータの楽曲のトラックデータが「Track 1」を示すものであるかを判断する。そして、それらの両要件を満たした楽曲のオーディオデータファイルへプライオリティデータを埋め込む。よって、シングルＣＤの最初に収録されるような極めて人気の高い楽曲（シングルカット曲）のオーディオデータファイルについてのみ、プライオリティデータを埋め込むことができる。

（第６実施形態）
本発明の第６実施形態について、以下、図面を参照しながら説明する。

第２実施形態では、あるオーディオデータファイルの楽曲の曲名およびアーティスト名をキーとしてＣＤデータベース１６から特定したレコードと「曲名」のフィールドの記憶内容を同じくする別のレコードがあるとき、つまり、同じ楽曲を収録した２以上のＣＤがあるとき、プライオリティデータをそのオーディオデータファイルへ埋め込むようになっている。これに対し、本実施形態では、いくつのＣＤに収録されている楽曲かに応じ、オーディオデータファイルに埋め込むプライオリティデータをランク分けする。

本実施形態にかかるデータ配信システムをなす、楽曲メタデータ配信装置１０、オーディオ再生記録装置３０、パーソナルコンピュータ５０、およびモデム６１のハードウェア構成は上記の５つの実施形態と同様であり、再度の説明を割愛する。

次に、本実施形態の動作を説明する。図１２は、本実施形態の特徴的な処理を示すフローチャートである。このフローチャートに示す一連の処理は、一又は複数のオーディオデータファイルがハードディスクドライブ４４に記憶された状態で、操作部３７の操作を通じてそれらのいずれかが選択されると開始される。なお、選択の対象となり得るオーディオデータファイルは、他のオーディオ再生記録装置３０やパーソナルコンピュータ５０から伝送されたり、または、ネットワーク経由でダウンロードしたオーディオデータファイルであり、且つその後の操作部３７からの操作や楽曲メタデータ配信装置１０へのアクセスを通じて曲名とアーティスト名のタグデータが埋め込まれたオーディオデータファイルである。

オーディオデータファイルが選択されると、図７のステップＳ３００からステップＳ３２０と同様の処理が実行され（Ｓ８００からＳ８２０）、ステップＳ８２０にて、リクエストに含まれる曲名データ（「属性データ」の一部に相当）およびアーティスト名データ（「属性データ」の一部に相当）を記憶したレコードがＣＤデータベース１６にないとＣＰＵ１１が判断すると、図７のステップＳ３３０からステップＳ３４０と同様の処理が実行される（Ｓ８３０からＳ８４０）。

ステップＳ８２０にて、リクエストに含まれる曲名データおよびアーティスト名データを記憶したレコードがＣＤデータベース１６にあると判断すると、ＣＰＵ１１は、そのリクエストに含まれるものと同じ曲名データを「曲名」のフィールドに記憶したＣＤデータベース１６のレコードの数を特定し、その数を含むＨＴＴＰレスポンスをリクエストの発信元へ送信する（Ｓ８５０）。

ＨＴＴＰレスポンスを受信したオーディオ再生記録装置３０のＣＰＵ４０は、そのレスポンスに含まれる数が２以上であるか、つまり、自らがリクエストに含めて送信した曲名データがＣＤデータベース１６の２以上のレコードの「曲名」のフィールドに記憶されているかを判断する（Ｓ８６０）。

ステップＳ８６０にて、レスポンスに含まれる数が２以上であると判断したとき（Ｓ８６０：Ｙｅｓ）、ＣＰＵ４０は、その数が３以上であるか、つまり、自らがリクエストに含めて送信した曲名データがＣＤデータベース１６の３つ以上のレコードの「曲名」のフィールドに記憶されているかを判断する（Ｓ８７０）。

ステップＳ８７０にて、レスポンスに含まれる数が３以上であると判断したとき（Ｓ８７０：Ｙｅｓ）、ＣＰＵ１１は、「ランク１」のプライオリティデータをオーディオデータファイルへタグデータとして埋め込む（Ｓ８８０）。ステップＳ８７０にて、レスポンスに含まれる数が３以上でないと判断したとき（Ｓ８７０：Ｎｏ）、ＣＰＵ１１は、「ランク２」のプライオリティデータをオーディオデータファイルへタグデータとして埋め込む（Ｓ８９０）。「ランク１」のプライオリティデータは、楽曲の優先度が最も高いことを示すデータであり、「ランク２」のプライオリティデータは、優先度がその次に高いことを示すデータである。また、ステップＳ８６０にて、レスポンスに含まれる数が２以上でないと判断したとき（Ｓ８６０：Ｎｏ）、ＣＰＵ１１は、ステップＳ８８０およびステップＳ８９０を実行することなく、処理を終了する。

以上説明した本実施形態では、あるオーディオデータファイルの楽曲の曲名と同じ曲名データを記憶したレコードの数が２つであるときは、「ランク２」のプライオリティデータをそのオーディオデータに埋め込み、レコードの数が３つ以上であるときは、「ランク１」のプライオリティデータをオーディオデータに埋め込む。このように、同じ曲名の楽曲を収録したＣＤの数に応じて異なるランクのプライオリティデータを埋め込むことにより、曲名やアーティスト名をキーとして検索した複数のオーディオデータファイルを、プライオリティデータのランク別にソートして表示させることが可能となる。

（他の実施の形態）
本発明は、上述の実施形態に限定されることなく、種々の変形実施が可能である。

第１実施形態では、オーディオ再生記録装置３０が自らのＣＤドライブ３９に装填されたＣＤから取得したＴＯＣデータをＨＴＴＰリクエストに含めて楽曲メタデータ配信装置１０へ送信し、そのＴＯＣデータをキーとしてＣＤデータベース１６の検索を行うようになっている。これに対し、ＣＤのＰＣＭオーディオデータのオーディオ波形から得られるいわゆるサウンド指紋をキーとして、ＣＤデータベース１６の検索を行ってもよい。

上記第１から第６実施形態において、ＣＤデータベース１６は、楽曲メタデータ配信装置１０に設けられ、その楽曲メタデータ配信装置１０に宛てたリクエストに対するレスポンスに応じて、オーディオ再生記録装置３０がプライオリティデータの埋め込みの有無を判断している。これに対し、ＣＤデータベース１６をパーソナルコンピュータ５０に設け、このパーソナルコンピュータ５０がオーディオ再生記録装置３０からのリクエストに応じて同様の判断を行ってもよい。また、オーディオ再生記録装置３０のハードディスクドライブ４４にＣＤデータベース１６を設け、オーディオ再生記録装置３０がコンテンツデータシステムとして、自らのＣＤデータベース１６への問い合わせを基にプライオリティデータの埋め込みの有無を判断してもよい。また、楽曲メタデータ配信装置１０がプライオリティデータの埋め込みの有無を判断してもよい。

上記第１から第６実施形態において、オーディオ再生記録装置３０によってプライオリティデータが埋め込まれるファイルは、ＣＤをリッピングして得られるオーディオデータファイル、他のオーディオ再生記録装置３０やパーソナルコンピュータ５０から伝送されたオーディオデータファイル、または、ネットワーク経由でダウンロードしたオーディオデータファイルである。これに対し、チューナ３４やＡＤＣ３１を介して供給される信号から得たオーディオデータファイルへプライオリティデータを埋め込んでもよい。また、静止画像や動画像などといった、オーディオデータとは異なるコンテンツデータのファイルへプライオリティデータを埋め込んでもよい。

上記第４実施形態では、あるオーディオデータファイルの楽曲の曲名と同じタイトル名のＣＤがあるときに、そのオーディオデータファイルへプライオリティデータを埋め込むようになっている。これに対し、あるオーディオデータファイルの楽曲の曲名とまったく同じタイトル名でなくても、データをなす文字列の一致度が所定の範囲にあるような（例えば、一文字違い、大文字小文字の違い、片仮名と平仮名の違いなど）ＣＤがあるときに、そのオーディオデータファイルへプライオリティデータを埋め込むようにしてもよい。

上記第５実施形態では、あるオーディオデータファイルの楽曲の曲名およびアーティスト名をキーとしてＣＤデータベース１６から特定したレコードに記憶されたトラックデータの数が４つ以下であり、且つそのオーディオデータファイルのトラックデータが「Track 1」を示すものであるとき、プライオリティデータをそのオーディオデータファイルへ埋め込むようになっている。これに対し、あるオーディオデータファイルの楽曲の曲名およびアーティスト名をキーとしてＣＤデータベース１６から特定したレコードに記憶されたトラックデータの数が４つ以下であるときは、その楽曲のトラックデータが「Track 1」でなくてもプライオリティデータを埋め込むようにしてもよい。この変形例によると、両Ａ面ＣＤやカラオケＣＤの収録曲のオーディオデータファイルにもプライオリティデータを埋め込むことができる。また、上記第５実施形態において、ステップＳ５４０でプライオリティデータをタグデータとして埋め込んだ後、ステップＳ４８０で選択されたアーティスト名を示すタグデータを併せて埋め込むようにしてもよい。

上記第６実施形態では、オーディオデータに埋め込むプライオリティデータのランクを、「ランク１」と「ランク２」の２段階に分けている。これに対し、そのランクを３段階以上に分けてもよい。

上記第１から第６実施形態において、オーディオ再生記録装置３０は、ＳＤＲＡＭ４３やハードディスクドライブ４４を有し、そのＳＤＲＡＭ４３やハードディスクドライブ４４にオーディオデータファイルを記憶させるようになっている。これに対し、フラッシュメモリやＥＥＰＲＯＭなどのメモリデバイス、ＵＳＢ接続のストレージ機器などにオーディオデータファイルを記憶させるようにしてもよい。

本発明の第１から第６実施形態にかかるデータ配信システムの全体構成図である。 図１に示す楽曲メタデータ配信装置のハードウェア構成図である。 ＣＤデータベースのデータ構造図である。 図１に示すオーディオ再生記録装置のハードウェア構成を示す図である。 第１実施形態の特徴的な処理を示すフローチャートである。 第１実施形態の特徴的な処理を示すフローチャートである。 第２実施形態の特徴的な処理を示すフローチャートである。 第３実施形態の特徴的な処理を示すフローチャートである。 第３実施形態の特徴的な処理を示すフローチャートである。 第４実施形態の特徴的な処理を示すフローチャートである。 第５実施形態の特徴的な処理を示すフローチャートである。 第６実施形態の特徴的な処理を示すフローチャートである。

符号の説明

１０…楽曲メタデータ配信装置、３０…オーディオ再生記録装置、５０…パーソナルコンピュータ、６０…ＬＡＮケーブル、６１…モデム、１１，４０…ＣＰＵ（１１は「判断手段」、「第１の判断手段」、「第２の判断手段」に相当、４０は「第１の取得手段」、「第２の取得手段」、「第３の取得手段」、「埋込手段」に相当）、１２…ＲＡＭ、１３…ＲＯＭ、１４，４４…ハードディスクドライブ、１５，３５…イーサネット（登録商標）コントローラ、１６…ＣＤデータベース、１７…楽曲メタデータ配信プログラム、３１…ＡＤＣ、３２…ＤＡＣ、３３…ＤＳＰ、３４…チューナ、３６…ＵＳＢコントローラ、３７…操作部、３８…表示部、３９…ＣＤドライブ、４１…ＥＥＰＲＯＭ、４２…フラッシュメモリ、４３…ＳＤＲＡＭ、４５…アンテナ

Claims (9)

1. コンテンツデータを含む一または複数のコンテンツデータファイルを取得する第１の取得手段と、
   上記取得したコンテンツデータファイルに含まれるコンテンツデータの属性を示す属性データを取得する第２の取得手段と、
   複数のコンテンツデータの各集合体を示す集合体データとそれらの集合体をなす各コンテンツデータの属性を示す属性データとを各々対応付けて記憶した自装置のまたは外部のデータベースにおいて上記取得した属性データが複数の集合体データと対応付けられている場合に、プライオリティの高いデータであることを示すプライオリティデータを取得する第３の取得手段と、
   上記プライオリティデータを上記取得したコンテンツデータファイルに埋め込む埋込手段と、
   を備えることを特徴とするコンテンツデータファイル加工システム。
2. 前記データベースから、前記取得した属性データを特定し、その属性データが複数の集合体データと対応付けられているか否か判断する判断手段、
   をさらに備えることを特徴とする請求項１に記載のコンテンツデータ加工システム。
3. 前記埋込手段は、
   上記特定した属性データが複数の集合体データと対応付けられていると前記判断手段が判断したとき、その複数の集合体データの数に応じたプライオリティのランクを示すプライオリティデータを上記取得したコンテンツデータファイルに埋め込む、
   ことを特徴とする請求項２に記載のコンテンツデータファイル加工システム。
4. コンテンツデータを含む一または複数のコンテンツデータファイルを取得する第１の取得手段と、
   上記取得したコンテンツデータファイルに含まれるコンテンツデータの属性を示す属性データを取得する第２の取得手段と、
   複数のコンテンツデータの各集合体を示す集合体データとそれらの集合体をなす各コンテンツデータの属性を示す属性データとを各々対応付けて記憶した自装置のまたは外部のデータベースに上記取得した属性データとの一致度が所定値以上である集合体データが記憶されている場合に、プライオリティの高いデータであることを示すプライオリティデータを取得する第３の取得手段と、
   上記プライオリティデータを上記取得したコンテンツデータファイルに埋め込む埋込手段と、
   を備えることを特徴とするコンテンツデータファイル加工システム。
5. 前記データベースから、前記取得した属性データを特定し、その属性データをなすコード列との一致度が所定値以上である集合体データが前記データベースに記憶されているか否か判断する判断手段、
   をさらに備えることを特徴とする請求項４に記載のコンテンツデータ加工システム。
6. コンテンツデータを含む一又は複数のコンテンツデータファイルを取得する第１の取得手段と、
   上記取得したコンテンツデータファイルに含まれるコンテンツデータの属性を示す属性データを取得する第２の取得手段と、
   複数のコンテンツデータの集合体を示す集合体データ、集合体をなす各コンテンツデータの属性を示す属性データ、およびそれらのコンテンツデータの収録順を示す収録順データを各集合体ごとに対応付けて記憶した自装置のまたは外部のデータベースにおいて、上記取得した属性データとともに上記集合体データと対応付けられた属性データの数が所定の数よりも多く、且つ上記取得した属性データと対応付けられた収録順データが所定の条件を満たす場合に、プライオリティの高いコンテンツデータであることを示すプライオリティデータを取得する第３の取得手段と、
   上記プライオリティデータを上記取得したコンテンツデータファイルに埋め込む埋込手段と、
   を備えることを特徴とするコンテンツデータファイル加工システム。
7. 前記データベースから、前記取得した属性データを特定し、その属性データとともに前記集合体データと対応付けられた属性データの数が所定の数よりも多いか否か判断する第１の判断手段と、
   属性データの数が所定の数よりも多いと上記第１の判断手段が判断したとき、上記取得した属性データと対応付けて前記データベースに記憶された収録順データを基にコンテンツデータの収録順を特定し、特定した収録順が所定の条件を満たすか否か判断する第２の判断手段と、
   をさらに備えることを特徴とする請求項６に記載のコンテンツデータファイル加工システム。
8. 前記コンテンツデータファイルは、オーディオデータを含むオーディオデータファイルであり、
   前記属性データは、
   上記オーディオデータとともに媒体に記録されているＴＯＣデータ、上記オーディオデータの波形を示す波形データ、上記オーディオデータの収録者を示すアーティスト名データ、上記オーディオデータファイルのファイル名を示すファイル名データ、および上記オーディオデータが表す楽曲の名称を示す曲名データのいずれかまたは組み合わせである、
   ことを特徴とする請求項１から７のいずれか１項に記載のコンテンツデータファイル加工システム。
9. 前記第１の取得手段は、
   媒体に記録されたオーディオデータ、または、そのオーディオデータを所定のデータ圧縮アルゴリズムに従って変換して得たオーディオデータを含むオーディオデータファイルを取得し、
   前記第２の取得手段は、
   オーディオデータとともに前記媒体に記録されたＴＯＣデータを前記属性データとして取得する、
   ことを特徴とする請求項８に記載のコンテンツデータファイル加工システム。

Images