Sleep Away.mp3 に無効なビットストリームが含まれる件

こちらは最近MP3デコーダ開発者のお客様からご指摘をいただいた件です。Windows7 に同梱されている Sleep Away.mp3 にはヘッダに無意味なビットストリーム(いわゆるゴミ)が入っています。 そのようなファイルであっても、MP3 の規格 ISO/IEC 11172-3 には準拠しています。しかしMP3 デコーダの実装によってはこのことが問題となる場合があります。具体的には、ファイルが壊れていると表示されたり、ノイズが発生するなど、が考えられます。 影響を受けるデコーダの実装の例は以下のとおりです: ヘッダの Size フィールドに書かれている値を見てタグサイズを調べ、そのタグサイズ分だけ読み飛ばしたところから開始して最初の同期ワードを以ってフレームとする。 そのような実装になっているデコーダでは、Sleep Away.mp3 のオフセット 0x6ec1 からの同期ワード(と解釈できるワード:赤い枠の部分)から始まる部分をフレームであると認識します。そしてその部分をフレームとして読み出すと複数のフィールドに無効な値が入っているため、エラー状態になります。 問題の部分は、ISO/IEC 11172-3 にてらして考えますと、フレームとは解釈できませんので、単純に読み飛ばすことが期待されます。ここを読み飛ばして同期ワードを探していくと、0x6f54 (青い枠の部分)から始まる部分が候補として見つかります。こちらは仕様に準拠したフレームとなっていますので、この場所からデコードを開始すれば問題は起こりません。 デコーダ開発者の皆様にはご迷惑をおかけしますが、MP3エンコーダの実装によってはこのようなビットストリームが生成されることも一般にありますので、フレームと解釈できないビットストリームは単純に読み飛ばすように実装いただけますよう、よろしくお願い申し上げます。

0

楽しいハック講座 (4) Windows7 オーディオアーキテクチャの概要

こんにちは。日本マイクロソフトの我孫子です。今日は Windows7 のオーディオ再生・録音の仕組みについて、ハック講座らしくディープに解説していきます。 Win7 時代に ASIOは必要なのか、いわゆる「ビットパーフェクト」な再生に最適な環境は何か、などなどについて考えていく材料になればと思います。 ■Windows7 のオーディオアーキテクチャ まずは百聞は一見にしかず、ということで、図をご覧下さい。この図は、Win7 におけるオーディオの再生処理の内部動作を示しています。紙面の都合上、ここでは、「理想的な」ドライバが使われている場合のみが描かれており、「理想的でない」場合の内部動作は割愛しています。また、録音処理については大部分の矢印が逆方向になるだけですのでこちらも割愛しています。さらに、ユーザモードが詳細になっている反面、カーネルモードやハードウェアの詳細は割愛されています。それらについてはまた日を改めて取り上げる予定です。 ■理想的なドライバ 「理想的な」ドライバとは、以下のいずれかです。 UAA 準拠 (UAA: Unified Audio Architecture)  USB 接続で Microsoft のドライバ (usbaudio.sys) を使用する場合 IEEE 1394 接続で Microsoft のドライバ (avcaudio.sys) を使用する場合 PCI バス接続でデバイスベンダー提供の HDAudio ドライバを使用し、かつ、そのドライバが Windows7 Certified ロゴを取得している場合 デバイスベンダー提供のWaveRT ミニポートドライバを使用し、かつ、そのドライバが Windows7 Certified ロゴを取得している場合 「理想的でない」ドライバとは、以下のいずれかです。 UAA 準拠 PCI バス接続でデバイスベンダー提供の HDAudio ドライバを使用し、かつ、そのドライバが Windows7 Certified ロゴを取得していない場合 デバイスベンダー提供のWaveRT ミニポートドライバを使用し、かつ、そのドライバが…

0

楽しいハック講座(3) マルチメディア タイマー その 2

こんにちははらだんです。今回は以前予告した timeSetEvent API の動作をハックしていきます。(注:クラックではありません)   今回紹介する内容は、弊社から無償で公開されているデバッグ専用のツール Debugging Tools for Windows に同梱されているデバッガ (windbg) と公開デバッグ シンボルを使えば誰でも確認することができます。   調査する内容の概要は以下になります。詳細については以前の記事「timeSetEvent の制限事項と不具合について」を読んでいただけたらと思います。   お題: Windows XP で timeSetEven() を uDelay に 429,497 ms 以上かつ TIME_PERIODIC を指定して呼ぶと期待する時間が経過する遥か前にイベントが発火する。Windows Vista/Windows 7 ではこの現象は起きていない。この現象についてデバッグを行い動作を確認する。   詳細は以前の記事に譲るとして、このお題について以下の 4 点を確認します。 A. uDelay の上限が 1000 秒であることを実装から確認する B. Windows XP では 429496 ミリ秒を超えるとオーバーフローすることを確認する C. TIME_ONESHOT の場合なぜ B. の現象は再現しないかを確認する D….

0

timeSetEvent の制限事項と不具合について

  こんにちははらだんです。週末は雨というシーズンは終わりかな?という今日この頃です。いやもう終わってますね。週末雨の音を聞きながら部屋でごろごろしているのはわりと好きなのです。湿度が高くて暑いのはいやですが・・。   さて、本日は Multimedia API (mmsystem.h/winmm.lib)の timeSetEvent 関数についてのお話です。   お題:timeSetEvent の引数、 uDelay (イベント遅延)の最大値について   Windows XP の timeSetEvent() 関数には不具合があります。Windows Vista の timeSetEvent() には制限事項があります。     Windows XP の timeSetEvent() 関数について: MSDN のtimeSetEvent() の記述では「タイマでサポートされるイベント遅延の最小値から最大値までの範囲にない場合、関数はエラーを返します。」とあります。範囲はタイマー デバイスに依存するというわけですが、実際にはソフトウェアつまり API レベルで 1000 秒が最大という制限があります。   しかし、Windows XP ではエラーを返さないにもかかわらず(実際にタイマーが設定されます)設定したイベント遅延よりもはるかに短い時間で発火する現象が発生することがあります。具体的には timeSetEvent の引数で TIME_PERIODIC を指定した場合イベント遅延時間は 429,496 ミリ秒が最大で、それより 1 ミリ秒大きくなるとオーバーフローによりイベント遅延時間が 1 ミリ秒に戻ります。   これは引数で受け取った…

0

楽しいハック講座(1) マルチメディアタイマー

 こんにちは。わび~です。 今日はマルチメディアタイマーを楽しくハックしていきます。(注:クラックではありません)   マルチメディアタイマーは、使ってみると思ったより精度が出ないと言われますが、それはなぜでしょうか。 今回は特に周期タイマーを取り上げて、その謎に迫ります。 紹介する内容は、Microsoft のデバッガ (windbg) と公開デバッグシンボルを使えば誰でも確認できます。   こちらが本日の実験用のプログラムです。   #include “stdafx.h” #pragma comment(lib, “winmm.lib”)   void CALLBACK TimerCallback(UINT wTimerID, UINT msg, DWORD dwUser, DWORD dw1, DWORD dw2) { std::cout << “timer” << std::endl; return; }   int _tmain(int argc, _TCHAR* argv[]) { // タイマーを5個登録します。 timeSetEvent(1234, 0, TimerCallback, 0, TIME_PERIODIC); timeSetEvent(1234, 0, TimerCallback,…

3