本文へスキップ

HeartMuLa Transcribe は、歌声に特化した多言語の speech-to-text で、音声 URL を 1 つ送ると歌詞がテキストで返ります。オプションはなく、行ごとのタイミング・信頼度・話者ラベルは返りません。

最低価格 $0.05/回

プレイグラウンド

入力

音声からテキスト
0/1

音声ファイルをここにドロップ、またはここから選択 · 1 ファイル・1 件 90 MB まで・MP3 · WAV

0 / 1 ファイル
音声ファイルに直接解決する URL です。HTML を返すページは素材エラーとして失敗します。言語のヒントは不要ですし、受け付けてもいません。モデルは多言語で、音声から自分で判断します。 1 文字以上

送信と料金見積もりを有効にする前にアカウントを確認しています。

必須項目が 1 件未入力です:入力音声

出力

実行待ち

結果はここに表示されます。

入力を設定し、概算料金を確認してからモデルを実行します。

関連モデルと次のステップ

お探しのモデルが見つかりませんか?

必要なモデルと用途をお知らせください。次に何を追加するかを決めるチームに直接届きます。

仕上がったミックスから歌詞を取り出し、テキストとして返す

HeartMuLa Transcribe が受け取るのは音声の URL 1 つだけで、その録音で歌われている言葉をタスク上のテキストとして返します。言語の指定も、タイムスタンプの要求も、話者を分ける切り替えもありません。スキーマにその項目自体が存在しないからです。このカタログの中で、タスクをメディアファイルではなくテキストで終えるモデルファミリーはこれだけなので、メディアストレージには何も書き込まれず、ダウンロードの処理を組む必要もありません。課金は分単位ではなく文字起こし 1 回ごとなので、6 分の曲と 20 秒のフックがまったく同じ料金になります。

プレイグラウンド を開く
リクエストの項目
1 つ。audio_url — 音声そのものに解決する URL
出力
タスク結果に載る歌詞テキスト。ファイルも素材 URL もありません
課金
文字起こし 1 回ごと。音声の長さには依存しません
言語
多言語対応。検出した言語は通知されません
タスクの上限
送信から終了状態まで 3,600 秒
保存
メディア素材は作られず、アップロードした音声は 1 日後に削除
形
必須項目は 1 つ、それ以外はスキーマが弾きますリクエストボディは audio_url だけです。空でない URI 文字列で、音声そのものに直接解決する必要があります。ほかのキーは黙って捨てられるのではなく検証で失敗するので、文字起こしが返ってきたということは送った値がそのまま使われたということです。呼び出しごとに調整する対象はなく、連携が育っても同期し続けるべき設定表は生まれません。
出力
バケットの中のファイルではなく、タスク上のテキストここにある他のモデルファミリーは、最後に取得用のファイルを書き出して終わります。このエンドポイントはタスクそのもので終わり、結果の中に文字起こしが入っています。ダウンロードの工程はなく、14 日間のメディア保存にも何も入らず、クライアント側では素材一覧をたどる代わりにテキスト項目を読む分岐を 1 つ足すだけで済みます。
狙い
ミックスと戦う歌声のために調整されています歌われた 1 行は、圧縮され、重ねられ、リバーブに浸かり、同じ帯域の楽器と競り合った状態で届きます。汎用の音声認識モデルが学習していないのはまさにこの状況で、断片しか返せなくなりがちです。このモデルはそこに合わせて調整されています。逆に、戦う相手のミックスがないインタビューやポッドキャストなら、汎用の音声認識のほうが適した道具です。

HeartMuLa Transcribe API が得意なこと

  • 覚えたまま書けるリクエスト

    キーが 1 つ、文字列の値が 1 つ。維持すべきパラメータ表はなく、モデルへの依頼内容を静かに変えてしまう設定の組み合わせもなく、連携が育ったときの移行計画も要りません。スキーマが閉じているので、キー名のタイプミスはその場で無効なリクエストとして返ります。適用したつもりの設定で文字起こしが作られてしまう、という事態が起きません。

  • 歌詞テキストはタスクそのものに届きます

    結果に文字起こしが直接載るので、取得する署名付き URL も、書き込む先のオブジェクトストレージも、ダウンロード済みファイルの後片付けジョブも必要ありません。既にメディアタスクを扱っているパイプラインに足すのは分岐 1 つです。このエンドポイントが終わったら素材一覧をたどる代わりにテキスト項目を読み、歌詞が既に置かれている場所へそのまま送ります。

  • 長さが料金に入り込みません

    課金は受理されたリクエスト 1 件ごとなので、音声の長さもサンプリングレートも、実際に返ってきた文字量も金額を動かしません。バックログの見積もりは総再生時間の関数ではなく、曲数 × 1 回あたりの単価という掛け算になります。裏返しも織り込んでおく価値があります。とても短いクリップを大量に流すと、処理した音声 1 分あたりでは相対的に割高です。

  • 言語項目なしの多言語対応

    モデルは複数の言語を自分で扱い、言語を宣言する項目はありません。多言語が混ざったカタログから、準備作業がまるごと消えます。呼び出し前の判定パスも、言語ごとのルーティング表も、言語違いによる再試行もありません。ただし、どの言語だと判断したかは報告されないので、そのラベルが必要なら自分のメタデータ側から用意してください。

  • どの行も歌われたとおりに返ります

    SpicyAPI は独自のコンテンツフィルタを重ねないので、罵り言葉や規制なしの歌詞は伏せ字にも自動の消音にもならず、そのまま文字起こしされます。権利確認、モデレーションのキュー、規制なしの音声プロダクトではこれが効いてきます。穴の空いた文字起こしでは、そうしたワークフローが本来問いたい質問に答えられないからです。音声と文字起こしの権利は引き続き利用者側が持ちます。

  • 非同期、そして意図的に広く取った上限

    送信するとすぐタスクが返り、文字起こしはそのタスクをポーリングするか、登録したコールバックを受け取って読み出します。上限は作成から終了状態まで 3,600 秒で、これほど広いのは順番待ちだけで 5 分を超えることが珍しくないからです。そのため数百曲のバッチも 1 つのワーカーから投げ、結果が届いた分から回収できます。

HeartMuLa Transcribe はどんな人に向くか

  • 音楽カタログとメタデータの担当

    旧譜の棚を「歌っている内容」で探せるようにする

    歌詞テキストがあれば、音声ファイルの棚が検索・タグ付け・照合・表示のできる対象に変わります。ここでロングテールを現実的にするのが 1 回あたりの課金です。ランのコストは総再生時間ではなく曲数で決まるので、10 分あるアルバムの締めの曲も、その前の短い間奏曲と同じ料金です。

  • ショート動画と字幕

    タイミングの前に、まず言葉を手に入れる

    音楽に重ねる字幕には、先に行が必要で、タイミングはその次です。このエンドポイントはテキストを渡します。タイミングは、同じ音声に対する強制アラインメントの工程が供給します。出力には行ごとの時刻も、確信度も、区切りも含まれないからです。この分担は、字幕の工程で気づくのではなく最初から設計に織り込むべきものです。

  • 信頼と安全、権利レビュー

    世に出す前に、その曲が実際に何と言っているかを読む

    年齢区分のラベルや権利の申し立てを判断する担当者に必要なのは、要約でも伏せ字版でもなく言葉そのものです。プラットフォーム側のフィルタをかけないので、文字起こしは録音の内容をそのまま映します。その判断に使えるのはこの形だけです。一方で、文字起こしは誰が権利を持つかまでは教えてくれません。その確認は利用者側に残ります。

  • 規制なしの音声プロダクト

    素材を拒まない文字起こしの工程

    汎用の事業者なら弾かれるカタログも、ここでは録音どおりに文字起こしされます。検索、タグ付け、アクセシビリティの機能が、プロダクトの他の部分と同じコンテンツの上で動き続けます。ライブラリの一区画だけテキストが一切ない、という状態になりません。素材とその権利についての責任は、引き続き呼び出す側にあります。

HeartMuLa Transcribe API の使い方

  1. audio_url はファイル本体に向けます。紹介ページではありません

    URL は音声データそのものを返す必要があります。期限付きの署名リンクも、有効なうちは問題ありません。再生ページ、共有リンク、その他 HTML を返すものは、1 行も文字起こしされないまま素材エラーになります。どちらなのか分からないときは、一度自分でその URL を取得して、何が返るか確かめてください。

  2. たった 1 つの項目を Idempotency-Key 付きで送ります

    ボディに入るのは audio_url だけです。返ってきたタスク ID を保存し、リクエストには Idempotency-Key を添えてください。キーは 24 時間有効なので、接続が切れた後の再送は元のタスクにつながり、別々に課金される 2 件目のタスクは作られません。

  3. 上限に近いタイムアウトで、ポーリングかコールバックを待ちます

    このエンドポイントは非同期です。間隔を広げながらポーリングするか、コールバック URL を登録してループ自体をなくします。3,600 秒の上限まで余裕を残してください。順番待ちだけで 5 分を超えることは珍しくなく、クライアント側を 1〜2 分で打ち切ると、正常に動いている処理まで失敗に見えます。

  4. タスクからテキストを読み、自分の側にも控えます

    文字起こしは結果にテキストとして届くので、ダウンロードするものはなく、メディアストレージにも現れません。プロンプトと同じ時期に消去されるため、永続的な控えはこちらではなく利用者側の保存先です。タスクが終了状態に達したその時点で、曲の ID の隣に書き込んでください。

  5. 流す前にバッチを選別します

    伴奏だけの音源はほとんど何も返しませんが、そのランも正常な終了状態に達しているので、他と同じように課金されます。大きなバッチの前に歌声の有無を確かめる工程は、すぐ元が取れます。6 秒のクリップも 6 分の曲も同じ料金だからです。音声は 1 つの作品に収まる長さにしてください。複数の曲を 1 ファイルにつなぐと、切れ目のない 1 塊のテキストとして返ります。

HeartMuLa Transcribe の実際の例

  • 公開ストレージにある 1 曲

    動く最小のコール。キーが 1 つ、音声を返す URL が 1 つ。ほかには何も受け付けず、何も必要ありません。応答はタスクレコードで、歌詞はそのタスクが終了状態に達した時点で結果の中に届きます。

    {"audio_url": "https://files.example.com/masters/track-07.mp3"}
  • 署名付きリンクの裏にある非公開ファイル

    公開していない素材でも、リンク自体が有効なうちに音声へ解決するなら問題なく動きます。署名の寿命は、直接ダウンロードに必要な数秒ではなく、5 分を超えることも珍しくない順番待ちを覆えるだけ取ってください。

    {"audio_url": "https://storage.example.com/takes/session-04.wav?X-Amz-Expires=3600&X-Amz-Signature=2f9c1a"}
  • 作業リストに沿った旧譜の一括処理

    リクエストが 1 項目なので、バッチとは URL のリストを 1 行ずつ回し、行ごとに Idempotency-Key を添えることです。各行が独立して精算されるため、失敗した 1 行はセット全体を流し直さずに再試行できます。ラン全体のコストもカタログの総再生時間ではなく、行数 × 文字起こし 1 回あたりの単価になります。

HeartMuLa Transcribe API のよくある質問

これは、たまたま音声を受け取るテキストサービスであって、たまたま言葉を返すメディアエンドポイントではありません。後工程で効いてくる違いはすべてそこから出てきます。クライアントはファイルを取得する代わりに項目を読み、こちらは文字起こしを長くは保持しないので保存の計画には自分の控えを含める必要があり、字幕にするなら自前のアラインメント工程が要ります。入口側で制御できるのは URL だけなので、結果を実際に良くする作業は、その URL が音声に解決すること、そしてその音声で誰かが歌っていることを確かめることです。