(57)【要約】【課題】一般的な内容をユーザーが容易に選択できる予め録音された音楽のための記憶フォーマットを提供する。【解決手段】メモリの最初に位置する汎用ヘッダは音楽チップの内容を成功裡に復号化するために必要な情報を特定する。これには、例えば、必要なビット速度、並びにチップ上でオーディオを記録するために採用された特定のＰＡＣ（Ｐｅｒｃｅｐｔｕａｌ  Ａｕｄｉｏ  Ｃｏｄｉｎｇ）に属する情報が含まれる。汎用ヘッダに加えて、各チップはテーブル内容に割り当てられた記憶部分を有している。テーブル内容は演奏時間、歌のタイトル、音楽のカテゴリー、並びにアーティストに関する情報を含んでいる。個々のヘッダは、例えば、トラックが属する音楽のカテゴリー、アーティスト、並びに各トラック選択をアドレスするための情報を含んでいる。ヘッダからの情報はチップがプレーヤー／ジュークボックス装置内にロードされたときに自己登録ないし自動的にダウンロードされる。【選択図】図１
2006113599.tif 000002
【特許請求の範囲】
【請求項１】
集積回路チップのメモリ内に予め録音されたオーディオを記憶する際に使用されるデータプロトコルにおいて、前記集積回路チップがオーディオプレーヤーとともに使用されるために適合されており、前記データプロトコルが、
メモリ内に前記予め録音されたオーディオを記憶するために使用された符号化技術に対応する内部記憶されたパラメータを有し、前記オーディオを復号化する際に前記オーディオプレーヤーにより使用される汎用ヘッダ（２２）、並びに
多数のデータフィールド（４０，４２，４４）を有する少なくとも１つの個々のヘッダ（３６）からなり、前記データフィールドが前記予め録音されたオーディオの個々のトラックに関する、オーディオのカテゴリおよび識別、およびトラックアドレスのような、一般の記述情報を含むことを特徴とするデータプロトコル。
【請求項２】
前記汎用ヘッダが前記メモリ内に記憶された前記予め録音されたオーディオを復号化する際に使用されるビット速度を特定することを特徴とする請求項１記載のデータプロトコル。
【請求項３】
前記個々のヘッダがオーディオの関連したトラックに対する音楽のカテゴリーを示すデータフィールドを含むことを特徴とする請求項１記載のデータプロトコル。
【請求項４】
前記個々のヘッダが前記個々のトラックに関連したアーティストを現すデータフィールドを含むことを特徴とする請求項１記載のデータフォーマット。
【請求項５】
前記個々のヘッダが前記個々のトラックの関連した１つのためのアドレス情報を含むことを特徴とする請求項１記載のデータフォーマット。
【請求項６】
前記アドレス情報が終了アドレスだけを含み、開始アドレスが暗示されることを特徴とする請求項５記載のデータプロトコル。
【請求項７】
前記汎用ヘッダおよび前記個々のヘッダが前記オーディオプレーヤー内で前記集積回路チップが電力投入されたときに自己登録されることを特徴とする請求項１記載のデータプロトコル。
【請求項８】
前記予め録音されたオーディオが前記少なくとも１つの個々のヘッダのすぐ後にメモリ内に符号化されることを特徴とする請求項１記載のデータプロトコル。
【請求項９】
前記少なくとも１つの個々のヘッダが前記汎用ヘッダの後に続き、前記個々のヘッダがオーディオの前記個々のトラックの１つに対応するアドレス情報を指定するデータフィールドの後に音楽のアーティストを指定するデータフィールドの後に音楽のカテゴリーを指定するデータフィールドを含んでいることを特徴とする請求項１記載のデータプロトコル。
【請求項１０】
前記個々のヘッダが歌のタイトル、演奏時間、および表示可能なグラフィックの中から選択される表示可能な情報を含むプリアンブルを含むことを特徴とする請求項１記載のデータプロトコル。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は音楽チップ内に含まれる種々のタイプのデータをラベル付けするためのプロトコルに関し、とくに、ヘッダの階層配置を含むプロトコルに関するものである。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
消費者の指定した音楽を記憶したりまた他のオーディオ用途のための種々の記録媒体が今日現在している。これらの媒体は、数例を挙げれば、ＣＤ  ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＤＡＴ（Ｄｉｇｉｔａｌ  Ａｕｄｉｏ  Ｔａｐｅ）および従来よりある磁気カセットオーディオテープなどである。上記の技術のうち、コンパクトディスクのフォーマットは密度が非常に増大したものであり、また使用のし易さは勿論のこと、デジタル的に記録されたオーディオの高い音質のために消費者の支持を得ている。
【０００３】
コンパクトディスクおよび他のフォーマットは、しかしながら、いくつかの顕著な欠点がある。１つは、コンパクトディスクはプレーヤーでの選択の前にディスク上の情報の内容を登録するための機能を通常は有していない。つまり、特定の音楽選択の内容に関する何等かの情報を得るために、何等かの方法でプレーヤーで手動で最初にアクセスされる際に選択しなければならない。一方、ＣＤプレーヤーのなかにはユーザーの入力に基づいて特定の選択を演奏するための手動でプログラムされるものがある。しかしながら、いずれの場合にも、ユーザーが選択についての予備知識がない限り、例えば、アーティスト、音楽タイプなどのカテゴリーにより自動的に検索して演奏する方法がない。このような知識は記録媒体上での選択の正確な場所、その場所へプレーヤーを向ける方法、並びに選択および場所についての検索可能なインデックスを最小限のものとして含んでいなければならない。主に記録媒体内の制限により、これらの機能の多くはコスト効率ないし効率的に達成することができない。よって、本発明の目的は、一般的な内容をユーザーが容易に選択できる予め録音された音楽のための記憶フォーマットを提供することにある。
【課題を解決するための手段】
【０００４】
本発明は音楽チップ内に含まれる種々のタイプのデータをラベル付けするためのプロトコルに関するものである。このプロトコルはチップ上の選択およびこれらがチップのメモリ内に符号化された方法に関する情報を記憶するためのヘッダの階層配置を含んでいる。メモリの開始に位置に位置する汎用ヘッダは音楽チップの内容を復号化するために必要な情報を特定する。これには、例えば、必要なビット速度、並びにチップ上でオーディオを記録するために採用された特定の符号化アルゴリズムに属する情報が含まれる。
【０００５】
汎用ヘッダに加えて、各チップはテーブル内容に割り当てられた記憶部分を有している。テーブル内容は演奏時間、歌のタイトル、音楽のカテゴリー、並びにアーティストに関する情報を含んでいる。個々のトラック選択は個々のヘッダによりテーブル内容の一部としてリストされる。個々のヘッダは、例えば、クラシック、ジャズ、カントリー、ロックなどのトラックが属する音楽のカテゴリー、アーティスト、並びに各トラック選択をアドレスするための情報を含んでいる。ヘッダからの情報はチップがプレーヤー／ジュークボックス装置内にロードされたときに自己登録ないし自動的にダウンロードされる。ヘッダ内に含まれる自己登録される一般情報の考え方によりユーザーは、ある時間期間演奏される、音楽のタイプ、アーティストなどによる選択ができる。
【発明を実施するための最良の形態】
【０００６】
以下に本発明の実施の形態を添付図面を参照しつつ詳細に説明する。
図１に、本発明のデータプロトコルフォーマットとともに使用される、音楽チップ１０の好ましい実施の形態を示した。この音楽チップ１０は、必須的にはメモリ内に含まれた音楽を演奏するための付随した固体オーディオプレーヤー内部に受領されるように適合されたメモリ要素である。チップ１０の物理的な特性は大体２．５インチ×１．１２５インチ×０．２５インチの寸法を有するものであり、高低のあるＡＢＳプラスチック（アクリルブチルスチレン）または同様な材料内に収容されている。比較的に適した寸法の音楽チップ装置はコンパクトディスクまたは他の媒体と比べて運搬性および記憶性に関して顕著な特長がある。チップ１０のメモリおよびインターフェース回路はパッケージ内に埋め込まれている。音楽チップ１０のメモリは予め録音された音楽あるいは他の同様な圧縮されたデジタルフォーマットで記憶されたオーディオ材料を含んでいる。
【０００７】
図２に、音楽チップ１０で使用されたメモリ構成およびデータプロトコルのフォーマット２０の本発明の好ましい例を示した。データプロトコル２０は必須的に音楽チップ１０上に記憶されたアドレスおよび音楽選択情報を得るために標準化されたフォーマットである。各音楽チップ１０はメモリの開始アドレス、例えばアドレス０ｘ０において汎用ヘッダ２２で符号化されている。汎用ヘッダ２２はチップ上の選択に関する一般的な情報およびこれらが符号化された方法などを含んでいる。より詳しくは、汎用ヘッダ２２は音楽２４の配給者、録音ラベル２６および著作権情報２８などを含んでいる。この情報はオーディオプレーヤーと関連した表示装置上に表示可能（および／または可聴）である。汎用ヘッダにはまた、チップ１０上の音楽が符号化された方法、つまり採用された特定の符号化アルゴリズムを特定するパラメータ情報３０が含まれている。
【０００８】
汎用ヘッダ２２のパラメータ情報は、圧縮技術が改良されたり、１つより多くのアルゴリズムを使用して、また異なるビット速度で単一のチップ上で符号化が可能になったりすることから、含まれることが好ましい。よって、特定のビット速度を使用して圧縮アルゴリズムを現在の品質に圧縮するよりはむしろ、各チップに対して公開された特定のアルゴリズムを発生するようにした方がよりコスト効率的である。これにより今日導入されている特定のアーティストからのアルバムを１２８Ｋｂｐｓで使用することができる一方、おそらくは３２Ｋｂｐｓで現在の１２８Ｋｂｐｓのものと同じ品質で演奏される同じアーティストからの将来のアルバムが異なるアルゴリズムを利用することができる。
【０００９】
汎用ヘッダ２２は、よって、音楽チップの内容を成功裡に復号化するのに必要なアルゴリズム３０とビット速度３２を特定するものである。この汎用ヘッダの特定のセクションに例えば１２Ｋより少ない情報を入力することで、本発明は音楽チップに関連したハードウェアがなんらかの特定のソフトバージョンで開始するのを阻止できる。この可転性によって与えられた演奏長さに対するメモリサイズを時間について減じることができて、チップあたりの価格を減じてマージンを増大できる手段が提供される。
【００１０】
上記したように、汎用ヘッダ２２はチップに関する選択およびこれらが符号化された方法についての情報を含んでいる。これおよび他のヘッダ情報はパワーアップまたは音楽チップの挿入された際に関連したオーディオプレーヤー内にアクセスされてチップの利用可能なトラック選択が決定される。各トラックに属するヘッダ情報はチップをキューアップ（ｃｕｅｉｎｇ  ｕｐ）しまた個々のトラック選択の間で巡回操作（ｎａｖｉｇａｔｅ）する際に逐次的に読み出される。
【００１１】
汎用ヘッダ２２に加えて、各チップはその中に内容テーブル３４の量が割り当てられたメモリのセクションを有している。トラック選択は個々のヘッダ３４によりこの内容テーブルの一部としてリストされる。内容テーブル３４は演奏時間、歌のタイトル、音楽のカテゴリーおよびアーティストに関する情報を含んでいる。内容テーブル内に含まれる情報によりチップ内容が、オーディオプレーヤー／ジュークボックス内に挿入する際に自己登録され、つまりダウンロードされる。
【００１２】
図２を再度参照して、個々のヘッダ３６を含む内容テーブル３４の一例が汎用ヘッダ２２の直ぐ後に示されている。プリアンブル３８は個々のヘッダ３６の前に示されており、プリアンブルは上記した演奏時間と歌のタイトルが含んでいる。プリアンブルまたは汎用ヘッダは同様にメモリコストの範囲で他の情報を含ませることができる。メモリチップ上に含まれる別の情報の例としては、アルバムの作品、印刷された歌の詩のような予め録音された音楽に対応するグラフィックデータを含むものであり、これらはオーディオプレーヤーと関連した表示装置上で見ることができる。表示装置はプレーヤー上の表示窓でもよく、あるいは遠隔操作のような遠隔で見ることができる表示器である。
【００１３】
個々のヘッダ３６は音楽カテゴリーは、例えばクラシック、ジャズ、カントリー、ロックなどの個々のトラックに関連した音楽のタイプを指定するものである。個々のヘッダ３６内の特定のトラック情報を記憶する考え方により、ユーザーは、音楽のカテゴリーにしたがって、アーティストにより、あるいは両方により、または他の基準によって音楽を選択することができる。例えば、ユーザーは夕方はカントリーウエスタンのカテゴリーからランダムに選択することができる。他方、ユーザーは特定のアーティスト、例えばＢｉｌｌｙ  Ｊｏｅｌの曲を聴くことを選択することができる。
【００１４】
個々のヘッダ３６のカテゴリーセクション（ＣＡＴ）４０は音楽のタイプの標準化された番号決めスキームに対応するものである。カテゴリーセクション４０は合理的な制限を有する予め決定された長さの固定フィールド、例えば、２５６のカテゴリーに対応する２進符号化された８フィールドを含んでいる。標準的な音楽のタイプのための３つの文字の短縮および対応するカテゴリー番号の例は、クラシック（ＣＬＳ＝０）、カントリー（ＣＴＹ＝１）、ゴスペル（ＧＯＳ＝２）、ジャズ（ＪＡＺ＝３）、ポピュラー（ＰＯＰ＝４）、ラップ（ＲＡＰ＝５）、レゲー（ＲＥＧ＝６）、リズムアンドブルース（ＲＮＢ＝７）、ロック（ＲＯＣ＝８）である。このリストは、当然であるが、種々の音楽タイプを含むために発展させることができる。
【００１５】
各音楽タイプへビット割り当ての詳細は標準化のためのものであり、新しい音楽タイプを収容するために周期的に更新される。カテゴリーコードおよびそのビット割り当ては音楽配給者、あるいはオーディオプレーヤーの製造業者などで入力される。
【００１６】
個々のヘッダ３６内に含まれるのはアーティストフィールド４２であり、これは２つの異なる方法の１つで符号化される。最初の方法では、カテゴリーコード４０の割り当てと同様な方法で各認識されたアーティストに特異ビットが割り当てられる。この方法は、しかしながら、音楽アーティストを制限なしにリストに含める場合には非常に多くのフィールドを必要とする。さらに、この符号化技術は新しいアーティストが出る際にアーティストの符号化を更新しつづけなければならないという問題がある。
【００１７】
第２の方法は、より効率的なものであり、アーティストの名前を短縮し次いで短縮の各文字を符号化する手順で構成される。例えば、アーティストＷｈｉｔｎｅｙ  Ｈｏｕｓｔｏｎのための短縮は次のようにして符号化される。
Ｗｈｉｔｎｅｙ  Ｈｏｕｓｔｏｎ→ＷＨＯＵＳＴ＝２３／８／１５／２１／１９／２０
但し、アルファベットコードは｛ａ＝１，ｂ＝２，ｃ＝３，…，ｚ＝２６｝
【００１８】
よって、各アルファベット文字は対応する番号コードが割り当てられ、アーティストの名前は予め定められた数の文字に短縮される。この意味はアーティストの名前を完全に表すことではなく、他のアーティストからのトラックを間違って選択する可能性を低くして特定のアーティストからの選択を迅速に同定するために走査できるフィールドを提供することにある。
【００１９】
アーティストの名前ないし識別が短縮されるこの種の符号化スキームは、テキスト圧縮に使用される数学的符号化技術に適用できる。数学的な符号化は、しかしながら、ビット割り当てにおける最も高い効率で得るために可能なアーティストの大きなデータベースを必要とし、またワードフィールドが非均一となる結果を生じる。このため、その処理が固定されたフィールド幅の考え方とは対照的だので、非均一なワードフィールドを利用する数学的符号化は好ましくない。非数学的に符号化された短縮は、しかしながら、いずれのアーティストの短縮を収納できる十分な長さの固定されたフィールドを利用することで処理可能である。
【００２０】
上記したように、アドレスフィールド４４は個々のヘッダ３６の他のセクションとして含まれる。アドレスフィールド４４に対しては２つの符号化スキームが可能である。図３を参照して、音楽選択のトラックアドレスを示すための第１の符号化スキームが示されている。図３にはプリアンブルフィールド３８が、また同様にカテゴリーフィールド４０およびアーティストフィールド４２が示されている。アドレスは各トラックに対する開始アドレス（ＡＤＤＲＢ）５２と終了アドレス（ＡＤＤＲＥ）５４を明確に特定することで行われる。これらのアドレスは各トラックの開始における個々のヘッダ情報３６から読み出される。この最初のアドレス符号化スキーム５０の復号化はＡＤＤＲＥＢ５２から開始し、ＡＤＤＲＥ５４に達するまで処理され、その際に新しいトラックが選択される。汎用ヘッダ２２と個々のヘッダ３６の情報に続くメモリチップ１０内の残りのメモリは適当なＰＡＣアルゴリズムを利用して記憶された実際の符号化された音楽が含まれる。
【００２１】
図４を参照して、第２のアドレス符号化スキーム６０が示されている。図３に示した第１の方法と同様に、このスキームはプリアンブルを利用し、また個々のヘッダにアーティストフィールド４０、４２をそれぞれ含んでいる。終了アドレス６２はアーティストフィールド４２の次に特定されている。第２のスキーム６０は予め規定された、固定された幅のヘッダフィールドにより依存しており、また開始および終了アドレスの双方を特定する必要がない（これらの１つだけが供給される）。よって、各トラックに対して１つだけのアドレスがアクセスのために必要となるので、この方法は記憶要件およびアクセス時間の点でより効率的である。固定されたフィールド幅を利用することで、音楽チップのトラック１に対応する符号化された音楽データは、完全なヘッダ情報、つまり汎用ヘッダ２２＋プリアンブル３８＋個々のヘッダ３６の終りで開始することが分かる。よって、開始アドレスは既知または暗示されるので、トラック１のアドレスフィールドは終了アドレス６２だけで特定される。次のトラックのための開始アドレスはチップ上の先のトラックの終了アドレス６２＋１アドレス場所、つまり先のトラックの終了アドレスより１多いものとして計算される。
【００２２】
トラックのランダム演奏特徴を希望する場合には、これは先のトラックの適当なヘッダ３６のアドレスフィールド６２をインデックスし、また所望のトラックに対する開始アドレスを回復するために１つ加えることで可能となる。音楽チップ１０上の最後のトラックのアドレスフィールド６２には、この選択を越して音楽内容が存在しないことを知らせるために「Ｅｎｄ−ｏｆ−ＲＯＭ」表示子で符号化される。
【００２３】
当然のことではあるが、本実施の形態の符号化スキームのアドレスフィールド６２は次のトラックの開始アドレスとして等価的に符号化することができ、この場合にはこのトラックのトラックの終了アドレスが暗示される。この方法は、先に説明したように、特定のヘッダに含まれるアドレス情報が符号化されたトラックに正確に属していない点において、終了アドレスを提供するよりも幾分直観的である。
【００２４】
音楽チップのための本発明のデータプロトコルは特定の音楽選択に関する一般的な情報に迅速且つ容易にアクセスすることができる。本発明の好ましい実施の形態では、ヘッダ、つまり汎用および個々のヘッダは、各トラックを正確に番号付けする必要性を省くために固定されたフィールド幅で符号化される。トラックｎに対するヘッダ情報は、次のアドレスでアクセスされる。
（汎用ヘッダ幅）＋［（ｎ−１）（個々のヘッダ幅）］
但し、ｎ＝トラック１、…，トラックＮ
【００２５】
汎用および個々のヘッダの階層配列内で音楽チップの内容に関する一般的な情報を供給することで、この一般的な情報はジュークボックスや家庭のプレーヤーに容易にダウンロードされ、ユーザーは手動でなんらかのハードウェアにプログラムすることなしにこの情報にアクセスすることができる。音楽選択はよってアーティスト、音楽のタイプあるいはこれらの両方に基づいて容易に行うことができ、単一あるいは多数の音楽選択を柔軟に行うことができる。
【００２６】
本発明のデータプロトコル階層ヘッダ配置の処理において重要なことは、ヘッダのためのスペースを提供する際に損失されるチップ１０上のメモリスペースの量である。現在の時点では、標準的な音楽チップ１０は２０Ｍバイト程度のリードオンリーメモリ（ＲＯＭ）を含んでいる。現在の符号化アルゴリズムを採用することで、チップ当たり４５分の演奏時間を確保できる。平均でトラック当たり３分として、音楽チップに１５曲ないしそれより多くのトラックを収容できる。各トラックのための１５の付属するヘッダの記憶に必要なメモリは音楽チップのメモリ容量の１％よりも少ないと考えられる。したがって、ヘッダ配列を記憶するために必要なメモリスペースは音楽チップの全体の記憶容量に影響を及ぼすことがなく、同時にユーザーに良好な選択性を提供できるものである。
【００２７】
以上、本発明の好ましい実施の形態を図面を参照して説明したが、これらは単に例示的なものであり、当業者には本発明の技術思想および範囲を逸脱することなく種々の変形や変更が可能である。これらの変更や変形は請求の範囲により規定された本発明の範囲内のものである。
【図面の簡単な説明】
【００２８】
【図１】本発明のデータプロトコルに関連して使用される音楽チップの好ましい実施の形態の上面図である。
【図２】ヘッダの階層配置を利用した本発明のデータプロトコルの好ましい実施の形態の説明図である。
【図３】個々のヘッダ内に含まれるアドレススキームの好ましい構成を示した説明図である。
【図４】個々のヘッダ内に含まれるアドレススキームの別の好ましい構成を示した説明図である。
【符号の説明】
【００２９】
１０  音楽チップ
２０  フォーマット
２２  汎用ヘッダ
３４  内容テーブル
【図１】
2006113599.tif 000003
【図２】
2006113599.tif 000004
【図３】
2006113599.tif 000005
【図４】
2006113599.tif 000006