ERI Developer's BBS
  新規投稿 ┃ ツリー表示 ┃ 一覧表示 ┃ トピック表示 ┃ 検索 ┃ 設定 ┃ ホーム  
4 / 9 ﾍﾟｰｼﾞ ←次へ　｜　前へ→
Vorbis RC-1？(^^;;
 猫次郎  - 02/8/6(火) 3:34 -
引用なし
パスワード
   ＞下に Copyright (c) 2001 とありますから、少なくとも去年です

112kbps までだと、RC-2 より以前の Encoder ですね。
RC-1？というか、beta.3 とか beta.4 とかの時だと思います。

ちなみに現在の Vorbis v1.0 の 64kbps の音質は素晴らしい
ものがあります(^_^;
個人的には「 情報の整理が上手い 」という感じかな。
Vorbis Stereo によるステレオイメージの圧縮による情報の
削減が功を奏しているのではないかと、そう思います(^-^;

今度、実験をする時は、mp3PRO、WMA v8、Vorbis v1.0 などと
比較実験をしてみると面白いかもしれません。ハイ(^_-ゞ
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 5.5; Windows 95)＠SODfi-01p3-144.ppp11.odn.ad.jp>
Re:性能評価の謎
 L.Entis  - 02/8/5(月) 18:20 -
引用なし
パスワード
   はじめまして、はとはと様。

▼はとはとさん：
>性能評価の音声非可逆圧縮編、歪み分析で突然OGGが112Kbpsで登場しているのですが(汗)
>まずは聞き比べ、には無いですし、なぜ112Kbpsなのかも謎ですが。
>現在のOGG Ver1.0でも64Kbpsは作成可能で、たしか１つ前のバージョンでも可能だったと記憶しています。
>すごく前だったのでしょうか？

日付が書かれていませんが、下に Copyright (c) 2001 とありますから、少なくとも去年です（年末だと思います）。
手元にあったOGGを出力できるプログラムが112kbpsまでしか対応していなかったのと、ただのサイン波ですとかなりレートが落ちますので、とりあえず64kbpsと比較しているわけです。

ではでは。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa2-92.kcom.ne.jp>
性能評価の謎
 はとはと  - 02/8/5(月) 10:14 -
引用なし
パスワード
   初めまして。

性能評価の音声非可逆圧縮編、歪み分析で突然OGGが112Kbpsで登場しているのですが(汗)
まずは聞き比べ、には無いですし、なぜ112Kbpsなのかも謎ですが。
現在のOGG Ver1.0でも64Kbpsは作成可能で、たしか１つ前のバージョンでも可能だったと記憶しています。
すごく前だったのでしょうか？

ちょっと気になったので書き込んでみます(^^;
Ver1.0はLPFがいじれるので、比較できるかもしれませんね。
波形は悪いが音がいいとかAVWatch(Impress)評価されていますが、

では、失礼します。
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)＠n094.nc2.kct.ne.jp>
Re:CPUID
 L.Entis  - 02/7/13(土) 21:10 -
引用なし
パスワード
   ▼/|/ |/さん：
>Illegal Instruction例外で強制終了させられたと思います、たしか。
>OS側で、命令をフィルタリングしているのかな？

それはナゾな現象ですね。
私のほうでも環境を探して試してみます。
もしそうだとすると、しかしある意味納得のいく動作ではあります。
私の想像ですが、コントロールレジスタ（CR#）に XMM の実行許可フラグなどが追加されていて、FPU のための EM フラグのようなものがあるのかもしれませんね（私の持っているIntelのPDFには普通のFPUと同様のようなので、これのみでは、OSが FPU レジスタを退避する処理をインプリメントしていれば（インプリメントの方法にもよりますが）、（レジスタの内容が正しくないものの）おそらくは実行されてしまいそうな気もしますが…）

>あとわ、IntelとかAMDのサンプルを見てると、
>SSE命令はxorps xmm0, xmm0 などxmmレジスタの浮動小数点演算を
>実際に実行してみる必要があるみたい？
>SSE整数命令だけではダメなのかもしれないです。

これはやっておいて損は無いと思うので、コードを挿入することにします。

>それから、SSEに関しては、bit24も見る必要があると思います。
>FXSAVE/FXRSTORをサポートしていないと、
>SSEの状態が退避できないので、実質使えないことになります？

FXSAVE、FXSTOR命令は、高速にレジスタを保存するための命令なので、SSE に対応しているOSであれば、この命令をサポートしていれば高速なレジスタ退避を、そうでなければ普通のレジスタ退避をやるのではないでしょうか？？

>あと、movhlpsとmovlhpsは、KatmaiのB-step以降でしか使えないそうなので、
>もし使用しているなら、そのチェックも必要かと思います。

今のところ使用していないのですが、今後使用する予定なのですが、SSE の中でもコードの切り分けをするのが面倒なので、SSE を検出したときに、この命令を実行してみるのが良いかもしれませんね(^^;
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa2-43.kcom.ne.jp>
Re:CPUID
 /|/ |/  - 02/7/13(土) 1:05 -
引用なし
パスワード
   >SSE は OS が対応していることが必須だと思いますが、同時に他に SSE を利用するアプリケーションが無い限り普通に動作すると思いますので、こんなんで行こうかと…。

というわけにもいかないのでわ？
Win95とかのSSE未対応OSで実行してみればわかりますが、
SSE命令を実行した瞬間に、
Illegal Instruction例外で強制終了させられたと思います、たしか。
OS側で、命令をフィルタリングしているのかな？

なので、ベンダに関わらず、SSE命令に関しては、
実際に命令が走るかどうかでの判定もあわせて行う必要があると思います。

どちらにしろ、ERINAライブラリはマルチスレッド対応だと思いますので、
１つのアプリでもSSEレジスタの退避をちゃんとやってもらえないと、
まずいことになるのではないかと。

あとわ、IntelとかAMDのサンプルを見てると、
SSE命令はxorps xmm0, xmm0 などxmmレジスタの浮動小数点演算を
実際に実行してみる必要があるみたい？
SSE整数命令だけではダメなのかもしれないです。

それから、SSEに関しては、bit24も見る必要があると思います。
FXSAVE/FXRSTORをサポートしていないと、
SSEの状態が退避できないので、実質使えないことになります？

あと、movhlpsとmovlhpsは、KatmaiのB-step以降でしか使えないそうなので、
もし使用しているなら、そのチェックも必要かと思います。

AMDだと、AMDの拡張フラグにもMMXに関してのフラグがなんかあるみたいなので、
そちらのチェックも必要な場合があるのかも？
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)＠m115193.ap.plala.or.jp>
Re:CPUID
 L.Entis  - 02/7/11(木) 22:24 -
引用なし
パスワード
[添付] 〜添付ファイル〜
・名前 ： cpuid.txt
・サイズ ： 3.1KB
   ▼/|/ |/さん：
>Featureフラグが立っていても、OSがサポートしてないとか
>BIOSの問題で動かないとかありうるので、
>Win環境では
>__try　__exceptブロックで囲んで試しに何かの命令を発行してみて、
>実際に使えるかどうかの確認は怠らない方が良いと思います。

とりあえず、Intel と AMD のベンダーIDを判定するようにして、それ以外の場合には、実際に命令が走るかどうかで判定するように、ERINA-Libraryの判定関数をコーディングし直してみました（添付ファイル）。
SSE は OS が対応していることが必須だと思いますが、同時に他に SSE を利用するアプリケーションが無い限り普通に動作すると思いますので、こんなんで行こうかと…。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa2-224.kcom.ne.jp>
Re:CPUID
 /|/ |/  - 02/7/10(水) 2:11 -
引用なし
パスワード
   追加です。
Featureフラグが立っていても、OSがサポートしてないとか
BIOSの問題で動かないとかありうるので、
Win環境では
__try　__exceptブロックで囲んで試しに何かの命令を発行してみて、
実際に使えるかどうかの確認は怠らない方が良いと思います。
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)＠i037070.ap.plala.or.jp>
Re:CPUID
 /|/ |/  - 02/7/10(水) 2:09 -
引用なし
パスワード
   私は、Featureフラグだけで十分かと思います。
Entisさんも仰ってるように、互換CPUはそのあたりも含めて互換にして
作っていますので、今のところ。
もしそのあたりの互換性のないCPUが出たら、
その時点で変更すればよいような気もします。
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)＠i037070.ap.plala.or.jp>
CPUID
 L.Entis  - 02/7/9(火) 23:56 -
引用なし
パスワード
   私が作っているライブラリ、ERINA-Librayr 等では、CPUID 命令で MMX や SSE の対応を判定していますが、判定の手順としてはじめにベンダーIDを見るという処理があります。
そこで、インテル純正CPUかどうかを判定してるわけですが、これは必ず行ったほうがよいものなのでしょうか？
…と言うのも、これを行ったときの問題点、及び疑問を列挙すると

(1) AMD などの互換CPUで MMX や SSE を使えない
(2) AMD 等の互換CPUでは FEATURE フラグも互換性があり、いきなり MMX や SSE の判定を行っても問題なさそうである
(3) そもそも、インテルに追従する互換 CPU では、こういった互換性を持たせることへ期待が持てる（もちろんこれは正しい処理ではないが）
(4) インテルも将来的に互換性を持たせることに期待が持てる
(5) そもそも互換性がなくなった時点で、それはサポート外なのでは？
(6) そうした場合には、別途そのような処理を行ったほうがよい気も…

ご意見お待ちしております。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa2-116.kcom.ne.jp>
Re:可逆DCTのアイデア
 L.Entis  - 02/6/29(土) 15:26 -
引用なし
パスワード
   ▼KAZさん：
>いいアイデア考えました。
>理論はいいかもしれないですが現実はうまくいきそうにない…
>音楽は一般に和音で構成されます。
>例えばオクターブ4のドがあれば周波数成分はその倍音が存在する確率が高いです。また和音の可能性も大きいのでミ、ソとその倍音成分の確率が高いです。
>これを上手くモデル化できればドラム、ノイズ音、不協和音には弱そうですが、高圧縮が望めるのではないかと。

具体的にどのような数学的手法を用いて倍音との冗長性を削減するかどうかがネックになりそうですね。
かなり難しそうです。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa2-121.kcom.ne.jp>
可逆DCTのアイデア
 KAZ  - 02/6/28(金) 23:48 -
引用なし
パスワード
   いいアイデア考えました。
理論はいいかもしれないですが現実はうまくいきそうにない…
音楽は一般に和音で構成されます。
例えばオクターブ4のドがあれば周波数成分はその倍音が存在する確率が高いです。また和音の可能性も大きいのでミ、ソとその倍音成分の確率が高いです。
これを上手くモデル化できればドラム、ノイズ音、不協和音には弱そうですが、高圧縮が望めるのではないかと。
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)＠R203222.ppp.dion.ne.jp>
MIO2
 L.Entis  - 02/6/27(木) 22:05 -
引用なし
パスワード
   MIO2 を早く手がけたい今日この頃。
忙しくて当分手をつけられそうにないのですが…。

今のところ、wavelet ではなく、現行の LOT の行列を拡張する形でバージョンアップしようと考えています。
現行の LOT は重複係数が 1 の固定になっており、これを引き上げる形ですが、行列の定義式を少し変えますので、重複係数が 1 の時には同じ行列になるのですが、2 以上になるときには（現行ではこの様なデータを書き出すプログラムあはありませんが）仕様上異なる結果になります。（予定）
まあ、一応下位互換と言うことで…(^^;

リリースは10月以降になる予定です。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa1-232.kcom.ne.jp>
Re:画像の縦横サイズ・・・
 L.Entis  - 02/6/24(月) 1:05 -
引用なし
パスワード
   ▼脱力さん：
>>インテルのCPUはリトルエンディアンですので、32ビットの整数 0x12345678 は、
>>バイト単位では、0x78, 0x56, 0x34, 0x12 の順に格納されます。
>
>インテル以外（MMXを含んでない場合なのかな）は上からなのでしょうか？
>ちょっと、気になったので（＾＾；

私的にはリトルエンディアン派なので(笑)、リトルエンディアンが最近は主流ではないかと思うのですが、インテルもPentium以降、ビッグエンディアンとリトルエンディアンを切り替えられるようになっていたと思います。ただ、互換性のため、普通リトルエンディアンしか使わないと思いますが。
PS2のプロセッサも両方使えたと思いますが、デフォルトはリトルエンディアンだったと思います。
一方、モトローラのプロセッサはビッグエンディアンです。X68000とかMacなどはビッグエンディアンです。

というわけで、エンディアンはプロセッサによってまちまちです。(^^;
486以降には、BSWAP というデータのエンディアンを変換する命令がありますので、アセンブラの場合、これを使うとデータの変換が簡単です。
C の場合、少々面倒ですけど…。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa2-236.kcom.ne.jp>
Re:画像の縦横サイズ・・・
 脱力  - 02/6/22(土) 22:01 -
引用なし
パスワード
   >インテルのCPUはリトルエンディアンですので、32ビットの整数 0x12345678 は、
>バイト単位では、0x78, 0x56, 0x34, 0x12 の順に格納されます。

インテル以外（MMXを含んでない場合なのかな）は上からなのでしょうか？
ちょっと、気になったので（＾＾；
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)＠133.15.121.65>
Re:画像の縦横サイズ・・・
 L.Entis  - 02/6/22(土) 1:11 -
引用なし
パスワード
   ▼脱力さん：
>こんにちは、脱力です
>ERIファイルをバイナリで開いて、画像の縦横のサイズを取得しようと思ったのですが
>なにやら、数字が逆から書き込まれているような・・・
>0x0050 のはずが　0x0500　と書き込まれてます・・
>
>ちょっと、構造体のメモリ内での扱いを知らないので
>逆になって当たり前なのかもしれませんが・・・
>
>ちょっと、DLL作成の時にファイルの縦横を取得する命令を
>省いたので、直接ファイルから読み込もうと思って行き詰まってしまいました
>
>まぁー、DLLに実装する予定ですが、この謎をもし説明できるのでしたら
>教えてもらえるとうれしいです

エンディアンの都合でバイト順序が逆になっています。
インテルのCPUはリトルエンディアンですので、32ビットの整数 0x12345678 は、バイト単位では、0x78, 0x56, 0x34, 0x12 の順に格納されます。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa2-32.kcom.ne.jp>
画像の縦横サイズ・・・
 脱力  - 02/6/21(金) 22:45 -
引用なし
パスワード
   こんにちは、脱力です
ERIファイルをバイナリで開いて、画像の縦横のサイズを取得しようと思ったのですが
なにやら、数字が逆から書き込まれているような・・・
0x0050 のはずが　0x0500　と書き込まれてます・・

ちょっと、構造体のメモリ内での扱いを知らないので
逆になって当たり前なのかもしれませんが・・・

ちょっと、DLL作成の時にファイルの縦横を取得する命令を
省いたので、直接ファイルから読み込もうと思って行き詰まってしまいました

まぁー、DLLに実装する予定ですが、この謎をもし説明できるのでしたら
教えてもらえるとうれしいです
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)＠133.15.121.65>
Re:MMX,SSE,SSE2すげー
 KAZ  - 02/6/18(火) 22:44 -
引用なし
パスワード
   >x86の初歩ですね(^^;
>inc DWORD PTR [eax]
>としましょう。
>ただ、メモリに対する操作は、
>add eax, mem
>mov mem, eax
>のような形が基本です。
どうもありがとうございます。CバージョンのソースをVC++の混合モードでみると似たような記述になってました。
で、Releaseでコンパイルすると自力アセンブラよりC++コードの方が早かったです…。やはり付け焼刃ではコンバイラには勝てないようです。
Intelのコンパイラは配列の操作などにかなりMMXとか適用してくれるらしく、パフォーマンスは高いようです。
それのコードを真似して書いてみてもいいかもしれません。
MSコンパイラが出してくれれば保守性はいいのですが。
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)＠U108051.ppp.dion.ne.jp>
Re:MMX,SSE,SSE2すげー
 L.Entis  - 02/6/18(火) 21:28 -
引用なし
パスワード
   ▼KAZさん：
>まだアセンブラよくわからず、とりあえず動くだけのとこも多いです。
>INC [EAX]はバイト単位でインクリメントしてしまいます。
>MOV EBX,[EAX]
>INC EBX
>MOV [EAX],EBX
>としないと32ビット単位でインクリメントしてくれないとか…

x86の初歩ですね(^^;
inc DWORD PTR [eax]
としましょう。
ただ、メモリに対する操作は、
add eax, mem
mov mem, eax
のような形が基本です。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa1-147.kcom.ne.jp>
大丈夫です
 L.Entis  - 02/6/17(月) 21:14 -
引用なし
パスワード
   ▼Kobarinさん：
>色々理由があって先頭の 16KB までしか調べてませんが、実用上は問題ないですよね？
>16KB を超える可能性高いでしょうかね。(^^;

16KBを超える可能性はほとんどないと思います。

>情報の取得だけなら、仕様書をよく読めば簡単に対応できますね。

そうですね。
書き換えるときは、上限値を超えないようにチェックしないといけないので、すこし大変ですね。
・ツリー全体表示
<Mozilla/4.75 [ja] (Windows NT 5.0; U)＠tokyo-fa1-221.kcom.ne.jp>
Re:あ…
 Kobarin  - 02/6/17(月) 19:54 -
引用なし
パスワード
   おかげさまでタイトルを取得できるようになりました。(^^)/
2.28β8 で対応しましたです。

http://home7.highway.ne.jp/Kobarin/KbMIDI/kbmed228_beta8.exe

色々理由があって先頭の 16KB までしか調べてませんが、実用上は問題ないですよね？
16KB を超える可能性高いでしょうかね。(^^;

情報を書き換えるわけではないので、読み込みに失敗したところで痛くも痒くも
ないからあまり気にしてませんが。

情報の取得だけなら、仕様書をよく読めば簡単に対応できますね。

> UNICODE のチェックもしないとまずいですね。

UNICODE でないデータを見たことがないので、UNICODE でないタグ情報を正しく
取得できてるかどうかあまり自信がありませんが、多分大丈夫でしょ。(^^ゞ
・ツリー全体表示
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705)＠m115224.ap.plala.or.jp>
  新規投稿 ┃ ツリー表示 ┃ 一覧表示 ┃ トピック表示 ┃ 検索 ┃ 設定 ┃ ホーム  
4 / 9 ﾍﾟｰｼﾞ ←次へ　｜　前へ→
ページ：  ┃  記事番号：
7920 C-BOARD v3.02 is not Free?