(57)【要約】【課題】状況に応じて適切な時間長でコンテンツを出力することができるようにする。【解決手段】ユーザ１がリクエスト３で音楽配信サーバ２にリクエスト曲２０の再生を要求すると、添付するメール４やフォーム５に記載される感想・エピソード９を反映して台詞１６が合成される。台詞合成処理１８では、楽曲データ１１に対応する前奏時間等を目標時間として、発声時間が近い台詞１６を台詞ＤＢ１７から選択する。台詞１６には、変数部分も設けられ、感想・エピソード９を反映させることができる。合成された台詞１６は、音声合成処理１４で音声化され、ディスクジョッキーやナレーションなどが台詞音声データ１２として付加された楽曲データ１１が配信され、ユーザ１の音楽プレイヤから再生される。【選択図】　　　図１
2004062769.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツデータが複数記憶されているコンテンツデータベースから、選択手段によって所望のコンテンツデータを選択し、選択されたコンテンツデータを出力手段によって出力するコンテンツ出力装置において、
出力するコンテンツデータの選択基準として、目標時間を指定する指定手段をさらに備え、
コンテンツデータベースには、各コンテンツデータが出力に必要な出力時間長とともに記憶されており、
選択手段は、コンテンツデータベースを検索して、各コンテンツデータの出力時間長と指定手段によって指定される目標時間とを比較し、比較結果が予め定める条件を満たすコンテンツデータを選択することを特徴とするコンテンツ出力装置。
【請求項２】
前記選択手段は、前記コンテンツデータを複数組合わせるときの前記出力時間長の合計値と前記目標時間との比較結果に基づいて、複数のコンテンツデータを選択し、
前記出力手段は、選択手段によって選択される複数のコンテンツデータを連続して出力することを特徴とする請求項１に記載のコンテンツ出力装置。
【請求項３】
前記コンテンツデータベースに記憶されているコンテンツデータには、他のコンテンツデータの挿入を指示するタグデータが含まれており、
前記選択手段は、該タグデータに従って組み合わされるコンテンツデータの前記出力時間長の合計値と前記目標時間との比較結果に基づいて、前記複数のコンテンツデータを選択することを特徴とする請求項２に記載のコンテンツ出力装置。
【請求項４】
前記タグデータは、状況に応じて値が変化する変数を指定するデータであり、
前記選択手段は、該タグデータによって指定される変数の現在の値に従って組み合わされる複数のコンテンツデータの出力時間長の和と前記目標時間との比較結果に基づいて、複数のコンテンツデータを選択することを特徴とする請求項３に記載のコンテンツ出力装置。
【請求項５】
前記コンテンツデータベースに記憶されているコンテンツデータには、状況に応じて値が変化する変数の値を指定する採用条件データが含まれており、
前記選択手段は、該採用条件データと指定される変数の現在の値との比較結果、およびコンテンツデータの前記出力時間長と前記目標時間との比較結果に基づいて、コンテンツデータを選択することを特徴とする請求項１〜４のいずれかに記載のコンテンツ出力装置。
【請求項６】
前記コンテンツデータベースに記憶されているコンテンツデータには、優先度データが含まれており、
前記選択手段は、該優先度データ、および前記出力時間長と前記目標時間との比較結果に基づいて、コンテンツデータを選択することを特徴とする請求項１〜５のいずれかに記載のコンテンツ出力装置。
【請求項７】
前記コンテンツデータベースに記憶されているコンテンツデータには、使用回数データが含まれており、
前記選択手段は、該使用回数データ、およびコンテンツデータの出力時間長と前記目標時間との比較結果に基づいて、コンテンツデータを選択することを特徴とする請求項１〜６のいずれかに記載のコンテンツ出力装置。
【請求項８】
前記出力手段は、前記選択手段によって選択される１または複数のコンテンツデータの総出力時間長が、前記目標時間と略一致するように、出力速度を変更して出力することを特徴とする請求項１〜７のいずれかに記載のコンテンツ出力装置。
【請求項９】
第１のコンテンツデータが複数記憶されたコンテンツデータベースから、選択手段によって所望の第１のコンテンツデータを選択し、選択された第１のコンテンツデータを出力するコンテンツ出力装置において、
第２のコンテンツデータを入力するコンテンツ入力手段と、
該第２のコンテンツデータに対応する属性データを入力する属性入力手段と、
属性入力手段に入力される属性データに基づいて、第１のコンテンツデータの目標時間を指定する指定手段とをさらに備え、
選択手段は、コンテンツデータベースを検索して、各第１のコンテンツデータの出力時間長と指定手段によって指定される目標時間とを比較し、比較結果が予め定める条件を満たす第１のコンテンツデータを選択し、
出力手段は、選択手段によって選択される第１のコンテンツデータと、コンテンツ入力手段に入力される第２のコンテンツデータとを合成して出力することを特徴とするコンテンツ出力装置。
【請求項１０】
前記属性入力手段によって入力される属性データは、前記第２のコンテンツデータに前記第１のコンテンツデータを重畳合成する時間位置情報および時間長情報を含み、
前記指定手段は、前記属性データに含まれる時間長情報に基づいて第１のコンテンツデータの目標時間を指定し、
前記出力手段は、該属性データに含まれる時間位置情報に基づく第２のコンテンツデータの時間位置に第１のコンテンツデータを重畳合成し、該合成されたコンテンツデータを出力することを特徴とする請求項９に記載のコンテンツ出力装置。
【請求項１１】
前記コンテンツは、言語情報を含み、
前記出力手段は、該言語情報を音声合成して出力することを特徴とする請求項１〜１０のいずれかに記載のコンテンツ出力装置。
【請求項１２】
コンピュータを、請求項１〜１１のいずれかに記載のコンテンツ出力装置として機能させるプログラム。
【請求項１３】
コンピュータを、請求項１〜１１のいずれかに記載のコンテンツ出力装置として機能させるプログラムが記録されるコンピュータ読取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、予め記憶されている言語情報などのコンテンツを、状況に合わせて出力するコンテンツ出力装置に関する。
【０００２】
【従来の技術】
従来から、たとえば高速道路の情報案内放送などに、コンピュータの合成音声で各種案内を行うシステムが用いられている。これらのシステムでは、必要な情報のみを繰返して出力するだけであり、一方通行で無味乾燥な出力内容となっている。
【０００３】
ラジオやテレビジョンの放送も、情報の一方通行であることに変わりはない。特に、音楽番組で記録媒体に記録されている音楽を再生するだけでは、再生する音楽の選択と、その音楽自体との魅力で聴取者を獲得しなければならなくなる。そこで、単に記録媒体に記録されている音楽を再生するだけの放送番組では、聴取の雰囲気を盛上げたり、付加価値を高めたりするために、ディスクジョッキー（以下、「ＤＪ」と略称する）やナレーションなどを組合わせる手法が発達している。ディスクジョッキーやナレーションは、発生者が種々の情報を音声で提供しながら、再生する音楽や広告（ＣＭ）などの間を調整し、パーソナリティや話題で視聴者を引付けることができる。ただし、ラジオやテレビジョンの放送は、予め決定されている時間スケジュールに従って行われ、聴取者は基本的に受動的である。放送する音楽などを選択するために、聴取者からのリクエストを利用するような工夫はあっても充分ではない。
【０００４】
近年、大容量の記録媒体の利用や、インターネットなどのデータ通信の利用で、音楽情報なども、必要な情報や希望する情報をいつでも選択して再生することができる環境が整うようになってきている。しかしながら、単に、音楽情報などを集めて再生するだけでは、無味乾燥な状態から逃れることはできない。このような状態は、ＤＪやナレーションが加われば、改善することができると期待されるけれども、一般に個々の視聴者に合わせて生身のＤＪなどを用意することはできない。そこで、コンピュータの音声合成機能や、録音音声再生機能を利用して、ＤＪやナレーションを追加することが考えられる。
【０００５】
従来、コンピュータの合成音声や録音音声再生でＤＪやナレーションの台詞を読み上げるシステムでは、あらかじめデータベース（以下、「ＤＢ」と略称することもある）に用意してある台詞を、「（適切なシーンで適切な台詞を喋るための）台詞を喋る条件」をもとに選択し、単語置換や台詞の接続などによって加工して再生する。しかし、音楽再生に合わせて前奏の部分でＤＪを行う場合などでは、台詞を喋る長さが曲によって異なるため、台詞が長すぎてＤＪが音楽のボーカルにかぶってしまったり、短すぎてＤＪの終わりとボーカルの開始との間があいてしまったりすることとなる。
【０００６】
特開２００１−２１００６５号公報には、ＭＤ（Ｍｉｎｉ　Ｄｉｓｋ　）などの記録媒体に記録されている音楽データを再生する音楽再生装置に音声合成出力機能を備え、ＴＯＣ（Ｔａｂｌｅ　Ｏｆ　Ｃｏｎｔｅｎｔｓ　）やＵＴＯＣ（Ｕｓｅｒ’ｓ　Ｔａｂｌｅ　Ｏｆ　Ｃｏｎｔｅｎｔｓ）などに記録されている曲番号、曲名等の曲管理データを表示以外の手段でユーザに知らせる先行技術が開示されている。この先行技術では、記録媒体に記録されている曲番号や曲名等をそのまま音声合成出力することとしており、台詞の長さ調節や適切な台詞の選択といった動作は行っていない。
【０００７】
【発明が解決しようとする課題】
特開２００１−２１００６５号公報に開示されているような音声合成出力機能を備える装置でも、音声合成出力する情報が単に曲番号や曲名等のみでは、放送番組で行われているＤＪなどとの差は大きく、雰囲気の盛上がりに欠けてしまう。
【０００８】
前述のように、音楽再生に合わせて前奏の部分でＤＪなどを行うようにすれば、音声合成や録音音声再生でも、放送などで行われているＤＪに近づけることができる。ただし、台詞の時間を調整する必要がある。台詞を喋る時間を適切な長さに調整したい場合、音声規則合成方式の場合は読み上げスピード、録音音声再生方式の場合は再生スピードを速くしたり遅くしたりして調節することが考えられる。しかしこれだけでは、たとえば、通常に喋ると３０秒かかる台詞を５秒で再生すると、不自然なほどに速いスピードで喋ってしまう。このように、台詞を決定した後の大幅な時間調整は困難である。
【０００９】
本発明の目的は、状況に応じて適切な時間長でコンテンツを出力することができるコンテンツ出力装置を提供することである。
【００１０】
【課題を解決するための手段】
本発明は、コンテンツデータが複数記憶されているコンテンツデータベースから、選択手段によって所望のコンテンツデータを選択し、選択されたコンテンツデータを出力手段によって出力するコンテンツ出力装置において、
出力するコンテンツデータの選択基準として、目標時間を指定する指定手段をさらに備え、
コンテンツデータベースには、各コンテンツデータが出力に必要な出力時間長とともに記憶されており、
選択手段は、コンテンツデータベースを検索して、各コンテンツデータの出力時間長と指定手段によって指定される目標時間とを比較し、比較結果が予め定める条件を満たすコンテンツデータを選択することを特徴とするコンテンツ出力装置である。
【００１１】
本発明に従えば、コンテンツ出力装置は、コンテンツデータが複数記憶されているコンテンツデータベースから、選択手段によって所望のコンテンツデータを選択し、選択されたコンテンツデータを出力手段によって出力するための選択基準として、出力するコンテンツデータの目標時間を指定する指定手段をさらに備える。指定手段は、たとえば楽曲データの前奏部分をデフォルトとして指定し、指定の変更を可能とする。コンテンツデータベースには、各コンテンツデータが出力に必要な出力時間長とともに記憶されており、選択手段は、コンテンツデータベースを検索して、各コンテンツデータの出力時間長と指定手段によって指定される目標時間とを比較し、比較結果が予め定める条件を満たすコンテンツデータを選択するので、出力されるコンテンツデータの出力時間長は予め定める条件を満たし、状況に応じて適切な時間長でコンテンツデータを出力することができる。
【００１２】
また本発明で、前記選択手段は、前記コンテンツデータを複数組合わせるときの前記出力時間長の合計値と前記目標時間との比較結果に基づいて、複数のコンテンツデータを選択し、
前記出力手段は、選択手段によって選択される複数のコンテンツデータを連続して出力することを特徴とする。
【００１３】
本発明に従えば、複数のコンテンツデータを選択するときに、複数のコンテンツデータの出力時間長の合計値が指定手段によって指定される目標時間に適合するようにするので、目標時間に合わせて選択されたコンテンツデータを連続して出力することができる。
【００１４】
また本発明で、前記コンテンツデータベースに記憶されているコンテンツデータには、他のコンテンツデータの挿入を指示するタグデータが含まれており、
前記選択手段は、該タグデータに従って組み合わされるコンテンツデータの前記出力時間長の合計値と前記目標時間との比較結果に基づいて、前記複数のコンテンツデータを選択することを特徴とする。
【００１５】
本発明に従えば、タグデータを含むコンテンツデータは、タグデータを変数として、タグデータの部分に種々の情報を追加し、全体として多様な情報を表現することができる。
【００１６】
また本発明で、前記タグデータは、状況に応じて値が変化する変数を指定するデータであり、
前記選択手段は、該タグデータによって指定される変数の現在の値に従って組み合わされる複数のコンテンツデータの出力時間長の和と前記目標時間との比較結果に基づいて、複数のコンテンツデータを選択することを特徴とする。
【００１７】
本発明に従えば、コンテンツデータに含まれるタグデータは、状況に応じて値が変化する変数を指定するデータであるので、状況の変化を反映してコンテンツデータを、出力時間が適切になるように選択することができる。
【００１８】
また本発明で、前記コンテンツデータベースに記憶されているコンテンツデータには、状況に応じて値が変化する変数の値を指定する採用条件データが含まれており、
前記選択手段は、該採用条件データと指定される変数の現在の値との比較結果、およびコンテンツデータの前記出力時間長と前記目標時間との比較結果に基づいて、コンテンツデータを選択することを特徴とする。
【００１９】
本発明に従えば、採用条件を満たすコンテンツデータを、目標時間を基準に選択して出力することができる。
【００２０】
また本発明で、前記コンテンツデータベースに記憶されているコンテンツデータには、優先度データが含まれており、
前記選択手段は、該優先度データ、および前記出力時間長と前記目標時間との比較結果に基づいて、コンテンツデータを選択することを特徴とする。
【００２１】
本発明に従えば、優先度データに従って優先度が高いコンテンツデータを、目標時間を基準に選択して出力することができる。
【００２２】
また本発明で、前記コンテンツデータベースに記憶されているコンテンツデータには、使用回数データが含まれており、
前記選択手段は、該使用回数データ、およびコンテンツデータの出力時間長と前記目標時間との比較結果に基づいて、コンテンツデータを選択することを特徴とする。
【００２３】
本発明に従えば、使用回数データを考慮したコンテンツデータを、目標時間を基準に選択して出力することができる。
【００２４】
また本発明で、前記出力手段は、前記選択手段によって選択される１または複数のコンテンツデータの総出力時間長が、前記目標時間と略一致するように、出力速度を変更して出力することを特徴とする。
【００２５】
本発明に従えば、複数のコンテンツデータを選択して、総出力時間長を目標時間に近づけ、さらに出力速度を変更して、複数のコンテンツデータを出力する総出力時間長を目標時間に合わせることができる。
【００２６】
さらに本発明は、第１のコンテンツデータが複数記憶されたコンテンツデータベースから、選択手段によって所望の第１のコンテンツデータを選択し、選択された第１のコンテンツデータを出力するコンテンツ出力装置において、
第２のコンテンツデータを入力するコンテンツ入力手段と、
該第２のコンテンツデータに対応する属性データを入力する属性入力手段と、
属性入力手段に入力される属性データに基づいて、第１のコンテンツデータの目標時間を指定する指定手段とをさらに備え、
選択手段は、コンテンツデータベースを検索して、各第１のコンテンツデータの出力時間長と指定手段によって指定される目標時間とを比較し、比較結果が予め定める条件を満たす第１のコンテンツデータを選択し、
出力手段は、選択手段によって選択される第１のコンテンツデータと、コンテンツ入力手段に入力される第２のコンテンツデータとを合成して出力することを特徴とするコンテンツ出力装置である。
【００２７】
本発明に従えば、コンテンツ出力装置は、第１のコンテンツデータが複数記憶されたコンテンツデータベースから、選択手段によって所望の第１のコンテンツデータを選択し、選択された第１のコンテンツデータを出力するために、コンテンツ入力手段と、属性入力手段と、指定手段とをさらに備える。コンテンツ入力手段および属性入力手段には、第２のコンテンツデータおよびその属性データをそれぞれ入力する。指定手段は、属性入力手段に入力される属性データに基づいて、第１のコンテンツデータの目標時間を指定する。選択手段は、コンテンツデータベースを検索して、各第１のコンテンツデータの出力時間長と指定手段によって指定される目標時間とを比較し、比較結果が予め定める条件を満たす第１のコンテンツデータを選択する。出力手段は、選択手段によって選択される第１のコンテンツデータと、コンテンツ入力手段に入力される第２のコンテンツデータとを合成して出力するので、第２のコンテンツデータに適合する第１のコンテンツデータを選択して、組合わせて出力することができる。
【００２８】
また本発明で、前記属性入力手段によって入力される属性データは、前記第２のコンテンツデータに前記第１のコンテンツデータを重畳合成する時間位置情報および時間長情報を含み、
前記指定手段は、前記属性データに含まれる時間長情報に基づいて第１のコンテンツデータの目標時間を指定し、
前記出力手段は、該属性データに含まれる時間位置情報に基づく第２のコンテンツデータの時間位置に第１のコンテンツデータを重畳合成し、該合成されたコンテンツデータを出力することを特徴とする。
【００２９】
本発明に従えば、第２のコンテンツデータを入力する際に属性データとして、第１のコンテンツデータを合成する時間位置や時間長の情報を入力し、第２のコンテンツデータに対して第１のコンテンツデータを適切に組合わせて、合成して出力することができる。
【００３０】
また本発明で、前記コンテンツデータは、言語情報を含み、
前記出力手段は、該言語情報を音声合成して出力することを特徴とする。
【００３１】
本発明に従えば、言語情報をコンテンツデータとして状況に応じて適切な時間で音声合成して出力することができるので、ＤＪやナレーションなどを付加してコンテンツを全体を予め設定される目標時間に合わせることができる。
【００３２】
さらに本発明は、コンピュータを、前述のいずれかに記載のコンテンツ出力装置として機能させるプログラムである。
【００３３】
本発明に従えば、目標時間が与えられると、コンテンツデータベースを参照して、コンテンツデータの出力時間が目標時間に適合するように、コンテンツデータを選択して出力するコンテンツ出力装置としてコンピュータを機能させることができる。
【００３４】
さらに本発明は、コンピュータを、前述のいずれかに記載のコンテンツ出力装置として機能させるプログラムが記録されるコンピュータ読取り可能な記録媒体である。
【００３５】
本発明に従えば、目標時間が与えられると、コンテンツデータベースを参照して、コンテンツの出力時間が目標時間に適合するように、コンテンツデータを選択して出力するコンテンツ出力装置としてコンピュータを機能させるプログラムをコンピュータに読込ませて動作させることができる。
【００３６】
【発明の実施の形態】
図１は、本発明の実施の一形態として、ユーザが発信したリクエストを受け、ＤＪ付の放送形式で再生するコンテンツ出力装置の概略的なシステム構成を示す。図２は、図１の全体的な動作を示す。以下、図１および図２を参照して、本実施形態の構成および動作の概要を説明する。
【００３７】
本実施形態では、ユーザ１が発信したリクエストを、インターネットなどのデータ通信ネットワークを介して、音楽配信サーバ２がコンテンツ出力装置として受付け、コンテンツとしての台詞によるＤＪ付の放送形式で再生する。ユーザ１が行うリクエスト３の送信は、メール４として、特定フォーマットに従って書くことや、オペレータが人手で情報入力することによるか、フォーム５として、ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）上のページのフォームや、パーソナルコンピュータ（ＰＣ）で動作しているアプリケーションプログラムのフォームなどに従って入力することが考えられる。
【００３８】
ユーザ１が送信したリクエスト３は、ステップＳＡ−０から動作を開始する音楽配信サーバ２が、ステップＳＡ−１で受信する。リクエスト３には、音楽属性情報６として、リクエスト曲名７およびリクエスト者名８が含まれる。さらに感想・エピソード１０を含ませることもできる。ステップＳＡ−２では、感想・エピソード１０が有るか否かを判断する。有ると判断されなければ、ステップＳＡ−４で曲名が未記入であるか否かを判断する。リクエスト曲名７が記入されていれば、ステップＳＡ−５で、リクエスト曲名７に基づいて音楽ＤＢ１０から楽曲データ１１を取得する。リクエスト曲名７として、予め設定される番号やコードなどを用いることもできる。また、同一の楽曲データ１１に対して、複数の呼び方を該当させたり、ある程度の曖昧さも許容して、完全に正確でなくても対応可能にしておくこともできる。
【００３９】
ステップＳＡ−６では、楽曲データ１１が無いか否かを判断する。楽曲データ１１が有れば、ステップＳＡ−７でＤＪのための台詞合成処理を行う。コンテンツである台詞は、台詞音声データ１２として、楽曲データ１１とともに、音楽配信サーバ２がユーザ１に配信する配信データ１３に含まれる。台詞音声データ１２は、ステップＳＡ−８で、音声合成処理１４を行って作成する。
【００４０】
ステップＳＡ−７の音声合成処理１４は、音楽属性情報６に感想・エピソード９が含まれていれば、その感想データ等も含めて合成する。ステップＳＡ−２で感想データ有りと判断するときは、リクエスト３の受信時に、ステップＳＡ−３で、感想・エピソード９を属性情報ＤＢ１５に保存しておく。
【００４１】
音声合成処理１４で合成して音声化する対象となる台詞１６は、テキストデータであり、リクエスト曲にあわせて喋るように用意する。台詞１６は、台詞ＤＢ１７に、複数がその標準的な出力時間とともにデータベース化されて記憶されている。台詞ＤＢ１７に、台詞１６をテキストデータではなく音声データで持つ場合には、音声合成処理１４は必要ない。
【００４２】
ステップＳＡ−９では、予め指定される楽曲データ１１の前奏、もしくは間奏、後奏などの部分にコンテンツである台詞１６から作成する台詞音声データ１２を合成して、音楽配信サーバ２がユーザ１に配信する配信データ１３を生成し、ステップＳＡ−１０でユーザ１に配信データ１３を配信する。デフォルトの指定では、たとえば楽曲データ１１の前奏部分に台詞音声データ１２を挿入する。ステップＳＡ−４で曲名未記入と判断されるとき、またはステップＳＡ−６で楽曲データ無しと判断されるときは、ステップＳＡ−１１でエラーメッセージをユーザ１に配信する。ステップＳＡ−９またはステップＳＡ−１０が終了すると、ステップＳＡ−１２で全体の動作も終了する。ユーザ１は、配信データ１３を音楽プレイヤ１９などの再生装置で、リクエスト曲２０として再生し、ＤＪ付の状態で楽しむことができる。
【００４３】
配信データ１３の楽曲データ１１としては、ＰＣＭ（Ｐｕｌｓｅ　Ｃｏｄｅ　Ｍｏｄｕｌａｔｉｏｎ）ファイル等の非圧縮形式のファイルや、ＭＰＥＧ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅ　ｃｏｄｉｎｇＥｘｐｅｒｔｓ　Ｇｒｏｕｐ　）１のＡｕｄｉｏ　Ｌａｙｅｒ　ＩＩＩ　からＭＰ３と略称される形式などの圧縮ファイルが考えられる。楽曲データ１１の圧縮ファイルは、再生時のデコーダを用いて非圧縮の楽曲データに変換することができる。楽曲データ１１および台詞音声データ１２の双方がＰＣＭファイルの場合、音声ミキシングは技術的に難しくない。合成範囲で楽曲データ１１の再生音量ボリュームを下げることも技術的に困難はない。ミキシング後にこの非圧縮データを、エンコーダで楽曲データ１１の元の圧縮ファイルフォーマットに戻すことが考えられる。音楽ファイルではなくＡＶＩ（Ａｕｄｉｏ／Ｖｉｄｅｏ　Ｉｎｔｅｒｌｅａｖｅｄ　）やＭＰＥＧ２などの映像メディアの場合も、同様に非圧縮データに変換し合成する方法が考えられる。
【００４４】
なお、楽曲データ１１および台詞音声データ１２をそのままユーザ１の音楽プレイヤ１９に送付し、この音楽プレイヤ１９上で音声合成処理を行うようにすることもできる。このようにして、音楽プレイヤ１９でリクエスト曲２０の再生がＤＪ付で実行される。このＤＪには、前述のように、属性情報ＤＢ１５に記憶しているリクエスト３の感想等データを台詞合成処理時に利用することもできる。
【００４５】
図１の実施形態では、「音楽配信」を行うシステムであるので、音楽データや音楽属性情報、音声合成機能は音楽配信サーバ２側にある。しかし本発明は、サーバではなくクライアントとなるユーザ端末、たとえば携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ　Ｄｉｇｉｔａｌ　Ａｓｓｉｓｔａｎｔ）、モバイルＰＣ等にこういったデータや機能があった場合でも、同様の方法で適切な台詞を出力することができる。ユーザ端末側で台詞を作成する場合には、台詞に「ユーザ情報」を利用しやすくなると考えられる。たとえば本発明を利用し、「携帯電話で楽曲を再生中に、間奏時間を利用して、新着メール情報をＤＪで伝える」といった機能を実現する場合には、ユーザ端末側で台詞を合成するほうが実現しやすい。
【００４６】
図３は、図１に示す台詞ＤＢ１７の例を示す。台詞ＤＢ１７は、台詞テーブルＳＴと、採用条件テーブルＣＴとで構成される。台詞テーブルＳＴでは、コンテンツデータである台詞内容Ｓと秒単位の発声時間ＳＬ（ｍ秒）と、さらに採用条件番号ＳＮとが１セットになっている。　発声時間ＳＬは、その台詞を標準速度で読み上げたときにかかる時間である。採用条件テーブルＣＴは、採用条件番号ＳＮと採用条件Ｃとの対からなる。
【００４７】
図４は、図２のステップＳＡ−８での台詞合成処理１８の例を示す。図４では、台詞合成処理１８で採用する台詞１６を決定する処理の大まかな流れを示す。採用条件Ｃには条件式が記述され、この条件が成り立つ場合には、真となる採用条件番号をリストＴＬに列挙するとともに、同じ採用条件番号ＳＮを持つ台詞テーブルＳＴのレコードが台詞候補となる。このとき、台詞１６に状況によって変化する変数表記を用意する場合、この変数名ＶＮに適切な変数値Ｖを反映させる。なお、変数領域ＶＡは、台詞合成処理１８を実行するプログラムで用意しておく。
【００４８】
台詞内容Ｓの発声時間は、変数表現以外の部分についての長さとする。変数値Ｖの発声時間は不定のため、以下の方法でこの長さを取得することが考えられる。
▲１▼音声合成エンジンにこのテキストを与えて長さを計測：正確だが処理に時間がかかる。
▲２▼読みの長さから概算して取得：ひらがな読みに変更し、たとえば１文字０．５秒とする、など。
▲３▼表記の長さから概算して取得：ひらがなやカタカナを１文字０．５秒とし、漢字１文字０．８秒とするなど。
▲４▼よく使用する単語や表記については、その発声時間をテーブルとして持っておく。
【００４９】
図５は、図１の台詞合成処理１８の手順を示す。ステップＳ０から手順を開始し、ステップＳ１では属性情報ＤＢ１５から音楽属性情報を受け取る。台詞合成処理１８に必要な属性情報は、ユーザ１からリクエスト３として送られてきた情報と、属性情報ＤＢ１５からの参照情報を併用する。まず、扱う楽曲のキーとなるリクエスト曲名７および「アーティスト名」をユーザ１から送られてきた情報から確定し、この情報をもとに属性情報ＤＢ１５の各種情報を参照する。参照する情報としては、前奏、間奏、後奏などの時間、コメント、アーティスト近況等が考えられる。また、リクエスト者の情報であるリクエスト者名８および「リクエスト者住所」も情報として利用する。他にも、「音楽配信システム利用回数」など、ユーザ１に対応したデータを持つようにして、より複雑な台詞１４を実現する場合には、このユーザ１毎のデータもここで取得する。このユーザ１毎のデータは、ローカルに保存しておいていても、音楽配信サーバ２に直接保存していてもかまわない。ローカルに保存する場合は、Ｃｏｏｋｉｅと呼ばれるデータの形で、ユーザ１が音楽配信サーバ２にアクセスすると、自動的に送信するようにすることもできる。ユーザ１毎のデータには、楽曲データ１１に対してコンテンツを挿入する部分のユーザ１による指定を含めることもできる。
【００５０】
ステップＳ２では、変数値をセットする。ステップＳ３では、採用条件テーブルＣＴから、真となる採用条件番号リストＴＬを作成する採用条件チェック処理を行う。ステップＳ４では、採用条件番号リストＴＬに採用条件番号ＳＮがあるレコードの台詞内容Ｓに変数値Ｖを適用する。ステップＳ５では、発声時間ＳＬに変数値の発声時間を加算する。ステップＳ６では、発声時間ＳＬが目標時間ＰＬに近いレコードの台詞１６を選択する。ステップＳ７では、台詞１６を音声合成処理１４に渡す。ステップＳ８で台詞合成処理の手順を終了する。ステップＳ２〜Ｓ６については、以下でさらに説明する。
【００５１】
図６は、図５のステップＳ２で変数値をセットする処理内容を示す。まず、ステップＳ２−０から処理を開始し、ステップＳ２−１では、リクエスト３を送信したユーザ１に対し、ユーザ毎に保存している統計値を取得する。ここでは、このリクエスト者名８に基づいて検索される配信サービス利用回数である。初回のサービス利用ならば、１を入れる。次にステップＳ２−２で、今日はじめてのリクエストであるか否かを判断する。これが今日はじめてのリクエストでないと判断する場合、ステップＳ２−３に進み、配信サービス利用回数を増やし、ＤＪの会話状態をあらわす変数ＰＨＡＳＥを「挨拶」にセットする。ステップＳ２−２で、今日はじめてのリクエストではないと判断する場合には、ステップＳ２−４に進み、変数ＰＨＡＳＥを次に進める。ステップＳ２−３またはステップＳ２−４が終了すると、ステップＳ２−５で、現時刻をセットする。これは、第６図の「変数の定義」で説明するように、システムから受け取る時刻情報を用いて決定する。ステップＳ２−６で変数値のセットを終了する。
【００５２】
図７は、図５のステップＳ３で、採用条件テーブルＣＴから、真となる採用条件番号リストＴＬを作成する処理内容を示す。これは、図４に示す「採用条件チェック処理」に該当する。採用条件テーブルＣＴの各レコードの採用条件Ｃは、図５のステップＳ２でセットされた変数値を用いる条件式で構成されている。この処理では、この条件式が真となるすべてのレコードの採用条件番号を検出する。処理は、ステップＳ３−０から開始し、ステップＳ３−１では、整数カウンタｉを初期化する。採用条件番号ｉの採用条件をＣ［ｉ］と表記する。ステップＳ３−２では、整数カウンタｉが採用条件番号ＳＮの要素数未満であるか否かを判断する。ｉに対する判断が採用条件テーブルＣＴのすべてのレコードについて行われるまで、ステップＳ３−３で、採用条件Ｃ［ｉ］が真かどうかをチェックする。真の場合、ステップＳ３−４で、リストＴＬに採用条件番号ｉを追加する。ステップＳ３−４の後、またはステップＳ３−３で真でないと判断するとき、ステップＳ３−５で整数カウンタをインクリメントし、ステップＳ３−２に戻ってすべてのレコードについてチェックするまで、ステップＳ３−２〜ステップＳ３−５を繰返す。ステップＳ３−２でｉ＜ＳＮ要素数ではなく、すべての採用条件番号についてのチェックが終了したと判断するときは、ステップＳ３−６で処理を終了する。
【００５３】
以上説明した処理によって生成したリストＴＬには、今回真となる採用条件番号ＳＮがすべて追加されている。この採用条件番号ＳＮをもつ台詞のレコードを、台詞テーブルＳＴからすべて「台詞の候補」として抜き出す。図５の手順では、ステップＳ４でこのすべてのレコードに対して、変数領域ＶＡをもとに、変数値Ｖを反映させ、反映した変数値に対応する発声時間を、ステップＳ５でレコードの発声時間に加算し、ステップＳ６で最も適切な発声時間のレコードを決定する。
【００５４】
図８は、図５のステップＳ４〜ステップＳ６での処理内容を示す。まず、ステップＳ４−０から処理を開始し、ステップＳ４−１ではループカウンタｉを０に初期化し、最適な台詞を格納する変数ｊに、初期値として１番目の台詞レコードであるＳ［０］をセットする。なお、採用条件番号ｉの台詞内容をＳ［ｉ］と表記する。リストＴＬのｎ番目の要素をＴＬ［ｎ］と表記する。台詞ｊの発声時間をＳＬ（ｊ）と表記する。ＰＬは目標時間であって、曲の前奏、間奏、後奏の長さなどを指定とすることができ、デフォルトでは、たとえば前奏に指定される。音楽配信サーバ２の設置者側で、前奏、間奏または後奏のいずれでも、一定時間以上あればその時間を目標時間として指定するように設定することもできる。また、ユーザ１が目標時間をリクエスト３に含めることなどで指定することもできる。
【００５５】
まず、ステップＳ４−２で、すべてのレコードをチェックするために、ループカウンタｉがリストＴＬの要素数未満であるというループ条件を設ける。次に、ステップＳ４−３で、レコードの台詞内容Ｓに変数表現があるかどうかチェックする。ある場合、ステップＳ４−４で、図４に示す変数領域ＶＡから変数値Ｖをここに置換して反映させ、ステップＳ４−５で反映させた変数値Ｖに対応する発声時間ＳＬ（Ｖ）を、台詞ＳのレコードＴＬ［ｉ］の発声時間ＳＬ（Ｓ［ＴＬ［ｉ］］）に加算する。
【００５６】
ステップＳ４−３でリストＴＬのｉ番目の台詞内容Ｓ［ＴＬ［ｉ］］に変数がないと判断するとき、またはステップＳ４−５の処理が終了すると、ステップＳ４−６でレコード発声時間ＳＬ（Ｓ［ＴＬ［ｉ］］）が目標時間ＰＬ以内であるか否かを判断する。ない場合には、前奏などの目標時間ＰＬ中に台詞が収まりきれないことになるので、次のレコードのチェックにループを進める。
【００５７】
ステップＳ４−６でレコード発声時間ＳＬが目標時間ＰＬ以内と判断するときは、ステップＳ４−７で、発声時間ＳＬが、現在の最適台詞ｊの発声時間ＳＬ（ｊ）よりも大きいか否かを判断する。大きい場合、このレコードの台詞は、最適台詞ｊよりも目標時間ＰＬに近い台詞ということになる。この場合、ステップＳ４−８に進み、このレコードの台詞を、新たに最適台詞ｊとする。ステップＳ４−８の後、またはステップＳ４−６で発声時間ＳＬが目標時間を超えているか、ステップＳ４−７で発声時間ＳＬが最適台詞ＳＬ（ｊ）以下であると判断するときは、ステップＳ４−９に進み、ループカウンタｉをインクリメントし、ステップＳ４−２に戻って、すべてのレコードについてチェックするまで繰返す。ステップＳ４−２で、ループカウンタｉがリストＴＬの要素数以上、すなわちすべてのレコードのチェックが終了していると判断するときは、ステップＳ４−１０で処理を終了する。
【００５８】
図９は、図１で属性情報ＤＢ１５に属性情報を蓄えて、台詞合成処理１８で活用する状態を示す。属性情報は、ユーザ１によるリクエスト送信時に送信されるリクエスト３に、メール４やフォーム５の感想等の内容として含まれている。音楽配信サーバ２は、リクエスト受信のときに、その感想等の情報を抽出して、属性情報ＤＢ１５に蓄える。台詞合成処理１８のとき、属性情報ＤＢ１５に蓄えられている情報が活用される。
【００５９】
図１０は、図４に示す台詞合成処理１８において、再生する楽曲の前奏（もしくは間奏、後奏）の長さにあわせた台詞を選択する選択方法の例を示す。　前奏、間奏、後奏時間は、属性情報ＤＢ１５に記憶されているものとする。楽曲データから実測する方法も考えられる。楽曲データからの実測方法は後述する。前奏等の長さを取得すると、これを目標時間ＰＬとして設定する。目標時間ＰＬに最も近い発声時間ＳＬの台詞を使用する。歌唱と台詞によるＤＪとがかぶらないように、ＰＬ≧ＳＬとすることが望ましい。単純な候補選択の手順として、具体的には「ＰＬ≧ＳＬを満たして、かつ、ＳＬが最大となる候補を選ぶ」という、図８に示すような方法が考えられる。
【００６０】
この例では、単純に「一回の台詞で１つの台詞レコードを使用する」ように書いているが、実際には、一回のＤＪで、複数の台詞を組み合わせて使うことが考えられる。その場合も同様の発想で、適切な長さの台詞を合成すればよい。
【００６１】
台詞トータルの発声時間だけでなく、変数に使う値を決定するときにも、この「発声時間」を利用できる。たとえば、トータル１６秒の台詞を１５秒にしたいときには、変数値（たとえばリクエストの感想文など）を１秒短い他の表現や候補に変更することで対応可能である。
【００６２】
微妙な読み上げ時間の調整は、読み上げスピードの変化でも可能である。台詞データに、「読み上げスピード指示のパラメータ」を保持し、大事な部分をゆっくり読み上げると、より自然な台詞にすることができる。音声合成エンジンには、その再生テキストに「どのように読み上げるか（楽しく、悲しく、強く、優しく等）」タグを付与することができるものもある。この場合、合成音の大きさや高さ、音色が変化するのが一般的である。しかしスピードによる抑揚は自然な台詞出力には重要である。
【００６３】
たとえば、「曲名とアーティスト名との部分のみ、他の部分の読み上げ速度より少しゆっくり喋る」ことで、台詞をより自然に喋らせることができる。この時間変化を、台詞時間の微調整に利用することで、より効果的な台詞作成システムとなる。
【００６４】
具体的には、
（台詞の発声時間ＳＬ÷台詞の読み上げスピードＳＰ１＋曲名の発声時間ＳＬ２÷曲名の読み上げスピードＳＰ２＋アーティスト名の発声時間ＳＬ３÷アーティスト名の読み上げスピードＳＰ３）＝目標時間ＰＬ
となるようなスピードＳＰ１，ＳＰ２，ＳＰ３を、標準スピードに対する比として求めればよい。
【００６５】
たとえば、ＳＰ１を標準スピードの１倍で１とし、ＳＰ２＝ＳＰ３と定めると、次式によりＳＰ２，ＳＰ３が求まる。
【００６６】
ＳＰ２＝ＳＰ３＝（ＳＬ２＋ＳＬ３）÷（ＰＬ−ＳＬ）
またＳＰ１＝ＳＰ２＝ＳＰ３と定めると、
ＳＰ１＝ＳＰ２＝ＳＰ３＝（ＳＬ＋ＳＬ２＋ＳＬ３）÷ＰＬ
により、ＳＰ１，ＳＰ２，ＳＰ３が求まる。また、ＳＰ１，ＳＰ２，ＳＰ３をそれぞれ異なる値としてもよい。
【００６７】
図１１は、図４の「変数領域ＶＡ」内の変数定義テーブルの例を示す。図４で出現している変数は、「現時刻」、「配信サービス利用回数」、「ＰＨＡＳＥ」、「季節」、「今回リクエスト数」、「ＤＪ所」および「最後にお知らせ」の７つである。「現時刻」は、この定義テーブルに従い、実際の時刻に対応した値を使用する。たとえば、実際の時刻が午後３時２３分の場合、値は「午後」となる。「配信サービス利用回数」は、このユーザ１が過去に配信サービスを利用した回数にとなる。「ＰＨＡＳＥ」は、ＤＪがどんな台詞を喋る状態にあるか、その状態を示している。遷移の例については後述する。「季節」は、「現時刻」同様に、現在の月によって変化する。たとえば現在１月の場合には、「冬」となる。これらの日時に関する変数値は、ベースとなるシステムのサービスルーチンなどで変更する。「今回リクエスト数」は、現在何曲目のリクエストかを保持している。「ＤＪ所」は、現在再生すべき楽曲のどこに台詞を挿入すべきかを示す値である。値は「前奏」「間奏」「後奏」のいずれかとなる。「ＤＪ所」の決定方法に特に指定はないが、一例として次に示すような方法を採ることができる。
【００６８】
まず、デフォルトで「前奏」にＤＪするよう設定する。ただし、「前奏」が１０秒に満たない場合、「後奏」でＤＪする。「後奏」が１０秒に満たない場合、「間奏」にてＤＪする。前奏、間奏、後奏の指定がない場合、歌のないインストゥルメンタルのみの楽曲とみなし、ＤＪは曲とかぶらないように入れる。２曲続けて曲を流すような場合には、デフォルトを１曲目前奏、２曲目後奏でＤＪするようにする。このように、変数定義テーブルは、コンテンツである台詞の目標時間ＰＬを指定する指定手段として機能する。ただしこの指定は間接的である。
【００６９】
また、これらの値の中には、配信サービス処理終了後も保存しておく必要があるものもある。たとえば「配信サービス利用回数」などである。変数値データの保存場所はどこでもかまわない。すなわち、音楽配信サーバ２側に保存しても、ユーザ１が使用するクライアント側に保存してもかまわない。
【００７０】
図１２は、台詞決定のための図１０とは異なる手法を示す。図１０では、台詞の長さのみで台詞候補を決定しているけれども、ここでは、台詞決定の指標として他の要素が加わった場合について、その決定方法を説明する。
【００７１】
他の要素としては、「優先順位」や「台詞使用回数」を加えることができる。なお、図１２では、台詞内容Ｓに変数値が反映され、発声時間も変数の長さを加算したものとなっているものとする。台詞候補リストには、次式計算するスコアを付与する。スコアは目標出力時間長としての目標時間ＰＬとコンテンツデータである台詞の発声時間ＳＬとの比較結果に対応する。台詞候補リストをスコアでソートし、目的に最も適したスコアを持つ台詞候補を採用する。なお、選択に使用するパラメータとしては、次のようなものを含める。
【００７２】
発声時間ＳＬ：台詞の長さは、０〜２０００ｍ秒程度とする。
発声時間が目標時間に近いほど採用率を高くしたい。
【００７３】
優先度ＰＲ：０〜５の数字とする
０：できる限り採用してほしい台詞　　５：優先度の低い台詞
優先度が小さいほど採用率を高くしたい。
【００７４】
使用回数ＵＴ：０〜１００の数字とする
（１００回以上の使用はカウントしない）
使用回数が少ないほど採用率を高くしたい。
【００７５】
これらのパラメータをある程度平等に、またパラメータ同士の重み付けを行うため、各パラメータ値に定数ａ，ｂ，ｃなどをかけて次式のように加算する。図１２の例では、パラメータ値のレンジがそれぞれ０〜１００の範囲になるように定数を設定している。実際には、台詞の内容に応じて定数ａ，ｂ，ｃを適切にチューニングする必要がある。一般的には、ａをもっと大きくして発声時間を重視した方が適した台詞が出現すると考えられる。
【００７６】
スコアＳＣ　＝　ａ×（ＰＬ−ＳＬ）＋　ｂ×ＰＲ＋ｃ×ＵＴ
（ａ＝０．００５、ｂ＝２０、ｃ＝１）
このスコアＳＣの値が小さいほど、採用したい台詞となる。
【００７７】
目標時間（台詞をしゃべる限界の長さ）＝１６００ｍ秒のときのスコアを図で記している。
【００７８】
目標時間との比較結果では、上から５番目の台詞のスコアが２３．５で最小であり、最適な台詞となる。
【００７９】
しかし「絶対に採用したい台詞が候補にある場合」、優先的に採用することが要望される。たとえば、ユーザ１へのお知らせの台詞がある。この台詞が候補にある場合には必ず採用したい、というケースもありうる。この場合、「絶対に採用したい台詞」の優先度を０にしておき、スコアでソートする前に、優先度０の候補がないか確認し、あればこれを優先して採用する方法が考えられる。
【００８０】
このようにして、複数の要素を通して最適の台詞を得ることができる。台詞合成に使用する情報として、音楽属性情報以外にもさまざまな情報がある。たとえば、図４では、「さあ本日もやってまいりましたこの［現時刻］のひととき！」という台詞を例にしているが、［現時刻］という部分には、現在が午後１時だった場合には「午後」と入れたいとする。このような場合に、台詞に変数表現を用いる。変数には、システムから得られる時刻情報などをもとにするもの（現時刻、季節）と、ユーザ１ごとに保存する統計データをもとにするもの（配信サービス利用回数）と、現在の台詞合成処理内の状態をあらわすもの（ＰＨＡＳＥ、今回リクエスト数、ＤＪ所）などがある。台詞合成処理では、図５にステップＳ２として示すように、こういった変数値の初期化を行う必要がある。
【００８１】
一例として、図６では、「配信サービス利用回数」と「現時刻」および「ＰＨＡＳＥ」の初期値をセットしている。
【００８２】
図１３は、会話の状態をあらわす変数「ＰＨＡＳＥ」の遷移例の処理を示す。状態ＳＢ−０から処理を開始し、状態ＳＢ−１として、最初に必ず「挨拶」、次にステップＳＢ−２として「ｎ曲目紹介」に入る。状態ＳＢ−２からは、状態ＳＢ−２、ＳＢ−３、ＳＢ−４のすべてに遷移する可能性がある。状態ＳＢ−２が終了したあと、楽曲再生が終了するまで状態は次に遷移しない。その後、状態ＳＢ−２からは次のように遷移する。
▲１▼次のリクエストがすでに入っている
ｉ．前回の遷移状態がＳＢ−２の場合、状態ＳＢ−３へ遷移し、一息入れる会話とする。
ｉｉ．前回の遷移状態がＳＢ−３の場合、状態ＳＢ−２へ遷移して曲紹介に戻る。
▲２▼次のリクエストがまだ入っていない
ｉ．前回の遷移状態がＳＢ−２の場合、状態ＳＢ−３へ遷移し、一息入れる会話とする。
【００８３】
（しかしすでにサービス利用時間が長い場合には、状態ＳＢ−４へ遷移する）
ｉｉ．前回の遷移状態がＳＢ−３の場合、状態ＳＢ−４へ遷移して終わりの挨拶とする。
最後に、「終わりの挨拶」（状態ＳＢ−４）となる。
【００８４】
図１４は、楽曲データから前奏、間奏、後奏時間を実測する考え方を示す。これまでの説明では、前奏、間奏、後奏時間（開始時間とその長さ）を、属性情報ＤＢ１５より取得するようにしている。そこで、この情報を実測する具体的方法をひとつ紹介する。
【００８５】
楽曲データのすべてに、前奏、間奏、および後奏時間が記されているわけではない。この例では、楽曲データ１１と、その楽曲のカラオケデータ２２との差異をとって、その差異がない部分の情報２３から前奏、間奏、後奏部分を検出している。一般に、今日発売されている楽曲のシングルＣＤには、ボーカル入りの楽曲と、ボーカルなしのカラオケとが一緒に入っていることが多い。この２つのデータを比較して、同一となる部分はボーカルのない部分とみなすことができる。この「ボーカルのない部分」のうち、ある程度の長さを持つ部分を前奏、間奏、後奏部分とみなすことができる。
【００８６】
また、シングルＣＤには２曲以上の楽曲データ１１が収録されていることがある。この場合、シングルＣＤ内のどの曲が楽曲カラオケデータ２２なのかを特定する必要があるが、楽曲データ１１と楽曲カラオケデータ２２の「演奏時間」がほぼ同一なことを利用することでこれを機械的に特定することができる。
この実測作業は、音楽配信サーバ２側で予め測定しておいてもよく、楽曲再生時にリアルタイムに実施することも可能である。当然、楽曲再生側で楽曲データ１１と楽曲カラオケデータ２２の双方を受け取って実測することも可能である。
【００８７】
以上で説明しているように、本実施形態では、ＤＪやナレーションなどの台詞をコンテンツデータとして読み上げるシステムにおいて、状況に合わせて適切な長さの台詞を用意することができる。合成音声でＤＪするシーンとしては、以下が考えられる。
・音楽や映像といったマルチメディアコンテンツ再生にあわせて、その再生前、前奏、間奏、後奏、再生終了後に、再生する楽曲のさまざまな属性情報（曲名、アーティスト名、アーティスト活動状況）や、ユーザの情報（たとえば、携帯電話で楽曲を再生中に、新着メール情報を伝達する）をトピックとした台詞をＤＪする。
・ゲームの進行、状況にあわせて、そのシーンとシーンの合間に、ユーザを盛り上げる実況中継やナレーションを喋る。
・スケジュールがタイムテーブルで管理されており、与えられる時間枠が動的に変化しうる場合、その時間枠内でさまざまな告知、たとえばニュースや天気予報、その他トピックのナレーション、ＣＭなどを行う必要がある場合。
【００８８】
そこで、台詞を合成する際に、台詞を喋る時間の長さに合わせてそれに適した台詞を合成する。このために、台詞のもととなるデータを管理する台詞ＤＢ１７には、それぞれの台詞パーツデータにその「通常読み上げ時間長」を保管する。たとえば、この「通常読み上げ時間長」を利用し、台詞読上目標時間に近い長さの台詞候補には高得点を付与し、台詞候補を得点でソートし採用する際に優位になるようにすればよい。
【００８９】
このしくみの台詞ＤＢ１７を採用することで、喋る長さが動的な場合でも、状況に合わせてより適切な台詞を喋ることができる。また、会話の使用回数を保存したり、直前に喋った会話のログを参考にすることで、一度使用した会話を連続して使わないようにし、聞き手を飽きさせないようにすることができる。さらに、台詞データに優先度を付与することで、適切な会話を選択できるよう調節することができる。優先度を付与する方法としては、たとえば台詞テーブルＳＴのレコードに、項目として［優先度］を追加し、台詞候補からの選出時に利用するようにすればよい。
【００９０】
以上の説明では、配信データ１２に含まれる台詞をコンテンツとしているけれども、ユーザ１にとっては、楽曲データ１１も配信を受ける目的のコンテンツである。台詞を第１のコンテンツとすれば、楽曲データ１１は第２のコンテンツデータであり、図１の音楽ＤＢ１０は、第２のコンテンツデータを入力するコンテンツ入力手段とみなすことができる。このような音楽ＤＢ１０は、インターネット上に分散して構築することもできる。
【００９１】
なお、本発明は、音声だけでなく、映像やテロップ表示などをコンテンツデータとする場合へも適用して、出力する時間を合わせることができる。
【００９２】
【発明の効果】
以上のように本発明によれば、音声、映像やテロップなどを含むコンテンツデータが複数記憶されているコンテンツデータベースから、目標時間に基づいてコンテンツデータを選択するので、出力されるコンテンツデータの出力時間長は予め定める条件を満たし、状況に応じて適切な時間長でコンテンツデータを出力することができる。
【００９３】
また本発明によれば、複数のコンテンツデータの出力時間長の合計値が目標時間に適合するように選択するので、たとえば複数の台詞の組合せや、変数によって生成される台詞の組合せなど、目標時間に合わせて選択される複数のコンテンツデータを連続して出力することができる。
【００９４】
また本発明によれば、たとえば台詞に含まれる変数名などのタグデータを含むコンテンツデータで、タグデータの部分に、現時刻や、たとえば音楽情報についてのアーティスト、曲名、今回リクエスト数などの種々の情報を追加し、全体として多様な情報を表現することができる。
【００９５】
また本発明によれば、コンテンツデータに含まれるタグデータによって、たとえばアーティスト、曲名、現時刻、今回リクエスト数等の状況の変化を反映させ、コンテンツデータを出力時間が適切になるように選択することができる。
【００９６】
また本発明によれば、たとえば利用回数やリクエスト数などの採用条件を満たすコンテンツデータを、目標時間を基準に選択して出力することができる。
【００９７】
また本発明によれば、優先度が高いコンテンツデータを、目標時間を基準に選択して出力することができる。
【００９８】
また本発明によれば、コンテンツデータを、目標時間を基準に、使用回数を考慮して選択して出力することができる。
【００９９】
また本発明によれば、複数のコンテンツデータを、総出力時間長が目標時間に近づくように組合せ、さらに出力速度を変更して、総出力時間長を目標時間に合わせることができる。
【０１００】
さらに本発明によれば、コンテンツ出力装置は、たとえば台詞などの第１のコンテンツデータが複数記憶されたコンテンツデータベースから、選択手段によって所望の第１のコンテンツデータを選択し、選択された第１のコンテンツデータを出力するために、コンテンツ入力手段および属性入力手段に、たとえば楽曲データおよびその前奏や間奏時間などの第２のコンテンツデータおよびその属性データをそれぞれ入力する。第２のコンテンツデータとしての楽曲データなどに適合する第１のコンテンツデータとしての台詞データなどを、前奏時間や乾燥時間などに合わせて選択し、組合わせて出力することができる。
【０１０１】
また本発明によれば、第２のコンテンツデータ、たとえば楽曲データなどを入力する際に、属性データとして、第１のコンテンツデータ、たとえば台詞を合成する時間位置や時間長の情報を入力し、第２のコンテンツデータに対して第１のコンテンツデータを適切に組合わせて、合成して出力することができる。
【０１０２】
また本発明によれば、言語情報をコンテンツとして状況に応じて適切な時間で音声合成して出力して、たとえばＤＪやナレーションなどとして、コンテンツデータ全体を予め設定される目標時間に合わせることができる。
【０１０３】
さらに本発明によれば、音声合成機能などを有するコンピュータで音声合成機能に基づいて出力するコンテンツデータを、目標時間に合わせて選択して出力するように機能させることができる。
【０１０４】
さらに本発明によれば、目標時間に合わせてコンテンツデータベースを選択して出力するコンテンツ出力装置としてコンピュータを機能させるプログラムを記録しておき、コンピュータに読込ませて動作させることができる。
【図面の簡単な説明】
【図１】本発明の実施の一形態としてのコンテンツ出力装置の概略的なシステム構成を示すブロック図である。
【図２】図１の音楽配信サーバ２による配信処理の手順を示すフローチャートである。
【図３】図１の台詞ＤＢ１７の例を示すブロック図である。
【図４】図１の台詞合成処理１８の例を示すブロック図である。
【図５】図１の台詞合成処理１８の全体的な処理手順を示すフローチャートである。
【図６】図５のステップＳ２で変数値をセットする処理の手順を示すフローチャートである。
【図７】図５のステップＳ３で行う採用条件チェック処理の手順を示すフローチャートである。
【図８】図５のステップＳ４〜Ｓ６で行う処理の具体的手順を示すフローチャートである。
【図９】図１の台詞合成処理１８で属性情報ＤＢ１５に蓄えられる属性情報を利用する状態を示すブロック図である。
【図１０】図１で属性情報ＤＢ１５から発声時間と目標時間とを比較して、台詞の会話候補を選択する状態を示すブロック図である。
【図１１】図４の変数領域ＶＡに記憶される変数の定義の例を示す図である。
【図１２】図４の台詞合成処理で、台詞の採用率を、優先度、使用回数、スコアに基づいて決定する考え方を示す図である。
【図１３】図６のステップＳ２−４で次のＰＨＡＳＥに進めるためのＰＨＡＳＥの遷移状態図である。
【図１４】図１の楽曲データ１１から前奏時間等を実測する考え方を示す波形図である。
【符号の説明】
１　ユーザ
２　音楽配信サーバ
３　リクエスト
４　メール
５　フォーム
６　音楽属性情報
７　リクエスト曲名
８　リクエスト者名
９　感想・エピソード
１０　音楽ＤＢ
１１　楽曲データ
１２　台詞音声データ
１３　配信データ
１４　音声合成処理
１５　属性情報ＤＢ
１６　台詞
１７　台詞ＤＢ
１８　台詞合成処理
１９　音楽プレイヤ
２０　リクエスト曲
２２　楽曲カラオケデータ
２３　情報
【図１】
2004062769.tif 000003
【図２】
2004062769.tif 000004
【図３】
2004062769.tif 000005
【図４】
2004062769.tif 000006
【図５】
2004062769.tif 000007
【図６】
2004062769.tif 000008
【図７】
2004062769.tif 000009
【図８】
2004062769.tif 000010
【図９】
2004062769.tif 000011
【図１０】
2004062769.tif 000012
【図１１】
2004062769.tif 000013
【図１２】
2004062769.tif 000014
【図１３】
2004062769.tif 000015
【図１４】
2004062769.tif 000016