[過去ログ]
音声可逆変換ソフト総合スレ (1002レス)
音声可逆変換ソフト総合スレ http://egg.5ch.net/test/read.cgi/software/1219683003/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
44: 名無しさん@お腹いっぱい。 [sage] 2008/10/03(金) 04:45:00 ID:5mcTPKC50 >>43 またまたこんな時間ですみません。 signed intの件、納得しました。 というかFILE_OFFSET_BITSやoff_tって書いいただいてるのだからオフセットと察しろって話ですよね。 Lilithで変換したファイルをmetaflac --listで調べてみたところ、 〜前略〜 point 736: sample_number=707171328, stream_offset=2841139388, frame_samples=4608 point 737: sample_number=708129792, stream_offset=2844727800, frame_samples=4608 と、問題はなさそうです。 ちなみにfoo_flaccer.dllで変換したファイルはエラーとなりwikiのとおりseektableは存在してませんでした。 まぁ、実際うちの環境だけできないのかは解らないですが、 うちの環境でlibFLACでのエンコードに問題がでないコトは解ったので、 そのうち、うちの環境でもlibFLAC 1.2.1でエンコードできるソフトでも探してみようと思います。 ホントにご丁寧にありがとうございました。 http://egg.5ch.net/test/read.cgi/software/1219683003/44
45: 35 [sage] 2008/10/03(金) 23:23:50 ID:Gk/CpB0M0 >>44 Lilith は、もしかしてオンラインアップデートしていないバージョンを使ってる? 0.992 にアップデートすると、FLAC 1.2.1 が使われてる。 これ最新のFLACのライブラリのはずだよね。 ところで、以前の flac.exe (公式のコマンドラインプログラム)では、 余計な SeekTable を作成するという不具合があったけど、 今のは直ってるのかしら? たしか、曲長にかかわらず、100個だか1000個だか作成しちゃうっての。 短い曲のときは無駄だし、長い曲のときは数足りず、で まともに機能しないケースが存在すると指摘されてたような。 >>40 処理系=コンパイラと捉えるなら、処理系と書いた方がよかったかもね。 Win みたいに複数のコンパイラが用意されている場合、 それぞれで制限違ったりするので。 VC の場合、少なくとも 2008 では、_fseeki64 とか用意されている以上、 通常の fseek とかで 2GB 以上を扱えるようには出来ないんだろうな。 関数自体は、define で置き換えればよいわけだが、 データを保持する変数の型のほう変更するのが面倒そうだ http://egg.5ch.net/test/read.cgi/software/1219683003/45
46: 名無しさん@お腹いっぱい。 [sage] 2008/10/03(金) 23:24:08 ID:B97GWqQQ0 flac tgfでデフォルトの圧縮率や保存先が設定できず、いちいち設定->バッチ とやるのが苦痛なのですが、もっとマシなフロントエンドはないですか? http://egg.5ch.net/test/read.cgi/software/1219683003/46
47: 名無しさん@お腹いっぱい。 [sage] 2008/10/03(金) 23:53:13 ID:zbHi8B7I0 >>45 fseekで2GB以上のファイルを扱うのはLP64とかILP64な処理系じゃないと無理でしょ。 fseekoみたいにoff_tじゃなくてlongだから。 >余計な SeekTable を作成するという不具合 それってfoobar2000のpipe encoderがwavのヘッダに 適当なdataチャンクの大きさを書くのが原因のやつじゃないの? 1.2.0で--ignore-chunk-sizesが追加されてるけど、 これを付けるとそもそもseektableが作られなくなる。 http://egg.5ch.net/test/read.cgi/software/1219683003/47
48: 35 [sage] 2008/10/04(土) 01:31:59 ID:FD/w9THf0 >>47 いえ、flac.exe 本体のバグ(?) です。 かなり昔の話だけど、確か Lilith の HP で見た気がしたので、 作者の書き込みかと思ってたら、ユーザの人の書き込みだったみたい。 ttp://www.project9k.jp/cgi-bin/innovationbbs/bbs.cgi?mode=one&namber=1212 2ch からは直リンできないんだったかな? みれなかったらURLコピペでよろすく http://egg.5ch.net/test/read.cgi/software/1219683003/48
49: 名無しさん@お腹いっぱい。 [sage] 2008/10/04(土) 01:55:54 ID:L6+WXtUj0 >>48 いや、それだとどうやってflac.exeを使ったかが分からないから wavヘッダのサンプル数が間違っている可能性は捨てきれないと思うけど。 サンプル数を越えたところにまで空のseekpointを作成というのは まさにその問題の典型だし。 http://egg.5ch.net/test/read.cgi/software/1219683003/49
50: 名無しさん@お腹いっぱい。 [sage] 2008/10/04(土) 12:09:03 ID:M36DJN+M0 >>45,47-49 LilithのVerの件ですが、ご指摘のとおり0.9.9.2にアップデートでlibFLAC 1.2.1になりました。 度々ホントありがとうございます。 一度オンラインアップデートしたんだけどなぁw SeekTableの件につきましては、 foobarというかPIPE処理等で事前にサンプル数が取得できない際におこるようです。 Seek Point計算はサンプル数が必須で、 例えば録音しながらPIPEで変換等は問題がでそうと考えます(サンプル数渡してもダミーだろぉし) ttp://www.project9k.jp/cgi-bin/innovationbbs/bbs.cgi?mode=one&namber=1215&type=1170 その後の1217で投稿した方もエンコード方法を認めております。 投稿日付にあわせて1.1.1のflacにてエンコードしましたが、flac -5 -o "E:\CL111.flac" K:\test.wavと引数を渡して、 options: -P 4096 -b 4608 -m -l 8 -q 0 -r 3,3と変化するようで、 -b 4608にてframe_samples=4608になる位しか目立った違いはありませんでした。 対策は>>47氏のおっしゃるとおり、chunkSizeを取得しない--ignore-chunk-sizesにて対応ってコトなんでしょうが、 >これを付けるとそもそもseektableが作られなくなる。 まさに作られませんでした。素人考えですがflacはSeek Tableの構造上PIPEエンコードにはむかないのかなぁと。 PIPE用にchunkSizeをみないのならば作成サイズも無視してくれるかと期待した部分もあったのですが、 あくまで、ヘッダのchunkSizeをみる部分を飛ばすだけって感ぢで、 サイズが解らないからSeek Tableも作らないだけってコトっぽいですね。 Lilithでのエンコードとflac.exeでのエンコードの違いでは、Seek Pointのframe samplesに違いがあり、 現在のflacはオフィシャルにあるようにデフォルトだとframe_samples=4096となり、(-0、-1、-2だと1152ですが) Lilithだと-b 4608としているようで、frame_samples=4608となりました。 あとはLilithはPADDINGのサイズを自分で付加するようになっていた位でしょうか? デフォルトだと0で当然METADATA blockにPADDINGはありませんでした。 そもそもうちがflac自体全く解っていないのでなんとも言えませんが、 METADATA block位置はtypeで見分けているので関係ないだろぉと推測して、違いはコレ位のようです。 http://egg.5ch.net/test/read.cgi/software/1219683003/50
51: 名無しさん@お腹いっぱい。 [sage] 2008/10/04(土) 13:56:24 ID:YQPA4Ds60 >>50 レポート乙 http://egg.5ch.net/test/read.cgi/software/1219683003/51
52: 名無しさん@お腹いっぱい。 [sage] 2008/10/04(土) 14:48:29 ID:L6+WXtUj0 >>50 >素人考えですがflacはSeek Tableの構造上PIPEエンコードにはむかない FLACはseektable無しでもシーク可能。seektableはシークを高速にするためにある。 >Lilithだと-b 4608としているようで、frame_samples=4608となりました 4096じゃないのはlilithがFLAC__stream_encoder_set_compression_levelを使ってないのが原因だな。 >デフォルトだと0で当然METADATA blockにPADDINGはありませんでした 今のFLACのフロントエンドはデフォルトで8192bytesのpaddingを付加するよ。 http://egg.5ch.net/test/read.cgi/software/1219683003/52
53: 名無しさん@お腹いっぱい。 [sage] 2008/10/04(土) 18:23:19 ID:M36DJN+M0 >>51 や、いつも長ったらしくてホントゴメンよぉ……、今回も長いけどw >>52 >FLACはseektable無しでもシーク可能。seektableはシークを高速にするためにある。 PIPEでファイル作成できない、もしくは他のエンコーダに劣るという訳ではなく、 PIPEによってFLACの特徴を一つ失うとなるならば、むいてるとは言えないのかなと。 PIPEを使わずにSeekTableありで変換できるのならばそちらを選ぶでしょうし。 >FLAC__stream_encoder_set_compression_levelを使ってないのが原因 frame samplesの違いは試してた際に特に気になっておりました。ありがとうございます。 >今のFLACのフロントエンドはデフォルトで8192bytesのpaddingを付加するよ。 あー、ゴメンなさい、書き方が悪かったです。Lilithの設定のデフォルト値の0だとってコトで、 flac.exeに関しては8192bytesのPADDINGをMETADATA block #3に確認しております。 ホントご丁寧にレスありがとうございました。 http://egg.5ch.net/test/read.cgi/software/1219683003/53
54: 名無しさん@お腹いっぱい。 [sage] 2008/10/04(土) 18:58:08 ID:M36DJN+M0 あー、わざとfoobarで--ignore-chunk-sizes外した結果を書いてなかったです。 ソースwavファイル詳細:24bit 96kHz 2ch 9:11 (551sec) 302 MB (317,494,364 バイト) flac.exe 1.2.1bでコマンドラインにてエンコード 184 MB (193,579,813 バイト) 〜前略〜 point 54: sample_number=51838976, stream_offset=189826283, frame_samples=4096 point 55: sample_number=52797440, stream_offset=193141717, frame_samples=4096 flac.exe 1.2.1bにてfoobarで--ignore-chunk-sizesあり 184 MB (193,578,801 バイト) type: 3 (SEEKTABLE)は無しで後はコマンドラインと同じ。 flac.exe 1.2.1bにてfoobarで--ignore-chunk-sizesなし 18.3 MB (19,232,591 バイト) 〜前略〜 point 744: sample_number=714240000, stream_offset=0, frame_samples=0 point 745: sample_number=715200000, stream_offset=0, frame_samples=0 PADDINGも変化あり length: 65536 flac.exe 1.1.1にてfoobarで--ignore-chunk-sizesなし 196 MB (206,409,944 バイト) 〜前略〜 point 743: sample_number=713906189, stream_offset=0, frame_samples=0 point 744: sample_number=714867032, stream_offset=0, frame_samples=0 PADDINGも変化あり length: 4096 流石にサイズが変わった1.2.1b--ignore-chunk-sizesなしはMD5やframesize、total samplesも変化がありましたが、 1.1.1に関してはSTREAMINFOの値も1.1.1のコマンドラインでの変換時と同じでSeek TabelとPADDINGのみの変化でした。 あくまでうちの場合はですが。 http://egg.5ch.net/test/read.cgi/software/1219683003/54
55: 名無しさん@お腹いっぱい。 [sage] 2008/10/04(土) 19:47:00 ID:L6+WXtUj0 >>53 別にパイプだと必ずダメと言う訳じゃないよ。 普通にシェルからcat hoge.wav | flac - -o hoge.flacとかやる分には何の問題もない訳で。 サンプル数が既知なのに、わざわざパイプで渡す時に チャンクサイズを不定にして渡すから問題になる。 だから47ではflacではなくfoobar側の問題という書き方をした訳だが。 スレ違いだがLAME 3.98のTLENタグなんかでも同じ問題が起こるはず。 http://egg.5ch.net/test/read.cgi/software/1219683003/55
56: 名無しさん@お腹いっぱい。 [sage] 2008/10/05(日) 06:00:45 ID:aBfFvcZR0 >>55 こんな時間ですみません。 >別にパイプだと必ずダメと言う訳じゃないよ。 ソレは実は解ってはいたんですが、変換元がwavファイルから渡すと確定していたり、 サンプル数が確定している場合がPIPE処理を使う前提の場合だと少ないのかなぁと思った訳です。 変換時に一時ファイルを作成したり、サンプル数が確定しているwavからの入力しかないと解るならば、 PIPE処理の必要性はあまりない気もしたので。 >LAME 3.98のTLENタグ どぉやら似たよぉな感ぢですね、ちと色々みてみます。 ホントにご丁寧にありがとうございます。 http://egg.5ch.net/test/read.cgi/software/1219683003/56
57: 名無しさん@お腹いっぱい。 [sage] 2008/10/05(日) 16:25:07 ID:dwFW1c500 PCDJとバックアップの為に音源をアナログからPCに取り込もうと思ってここ来たが、 PCDJ用途と考えると展開速度が速いFLACが良いのかな 勉強になる http://egg.5ch.net/test/read.cgi/software/1219683003/57
58: 名無しさん@お腹いっぱい。 [sage] 2008/10/05(日) 16:37:50 ID:IWv8Vcfq0 まあ、PIPE入力だと元がファイルではなくて終わりが決まっていないストリームの場合もあるから エンコーダ側ではサンプル数を当てにした処理は避けうるなら避けたほうがいいのかも。 その辺はフォーマットのファイル設計なんかも関わってくるよね。 http://egg.5ch.net/test/read.cgi/software/1219683003/58
59: 名無しさん@お腹いっぱい。 [sage] 2008/10/05(日) 17:30:58 ID:Tg7yoQeF0 FLACの場合はメタデータブロックがファイルの先頭(圧縮データより前)にあるから、 seektableを作る場合、圧縮前にあらかじめseekpointの数だけ領域を確保する。 この操作のためにサンプル数が事前に必要。 ちなみに何サンプル目にseekpointを置くかを決めればいいだけなので、 サンプル数はおおよそでOKで正確である必要はない。 エンコード後に実際のサンプル数を使ってseektableを更新できるのが理想だけど、 確保した領域の分よりも多くのseekpointが必要な場合、 メタデータブロック後の巨大な圧縮データを再配置する必要がある。 ただ、padding領域を使えばある程度までならメタデータブロックのみの再配置で済むから この程度の実装なら将来のFLACでやるかもしれない。 まあ、サンプル数が未知のPCMストリームをseektable付きで圧縮するという需要がどれだけあるか、だけど。 http://egg.5ch.net/test/read.cgi/software/1219683003/59
60: 名無しさん@お腹いっぱい。 [sage] 2008/10/06(月) 00:21:50 ID:+Ew7Qu3h0 ごめんマニアックだけど 普通のWAV(CD音質=44100Hz)以外のWAVでも対応してるのってありますか DTMしてるんで24Bit/48kHzで保存してたりするもんで。 http://egg.5ch.net/test/read.cgi/software/1219683003/60
61: 名無しさん@お腹いっぱい。 [sage] 2008/10/06(月) 00:31:25 ID:lIkuJkQR0 >>60 FLAC, WavPack, etc http://en.wikipedia.org/wiki/Comparison_of_audio_codecs#Technical_details http://egg.5ch.net/test/read.cgi/software/1219683003/61
62: 名無しさん@お腹いっぱい。 [sage] 2008/10/06(月) 00:43:36 ID:+Ew7Qu3h0 >>61 海よりも深くThx http://egg.5ch.net/test/read.cgi/software/1219683003/62
63: 名無しさん@お腹いっぱい。 [sage] 2008/10/06(月) 12:26:29 ID:K/cRAG+O0 >>58 うちもそんな感ぢで考えてました。 入力元がファイルで長さが決まっているならば別フォーマットから変換でも簡単にwavのサンプル数割り出せるぢゃんってのは、 書いた後直ぐに気づいたのですが/// >>59 >FLACの場合は 詳細な説明ありがとうございます。 >サンプル数はおおよそでOKで ってのが意外に感ぢしたが、きちんとchunkSizeを渡してなかった時もSeekTableを作ってはいたのに気づくべきでした。 ちと、foobarがstreamでなくファイルも何故サンプル数をきちんと渡していないか考えてみたのですが、 複数のファイルを選択し単一のファイルとして変換したり、未知の形式に対応する際に、 ファイルサイズでfoobar側がボトルネックになる可能性を排除しPIPEでエンコーダに渡し、 デコード後4GB以上のファイルでwavヘッダのchunkSizeが4byteを超える可能性も考え、計算することを避けたのかなぁと。 streamを扱う際と同等の処理でできるという方が強いのかもしれませんがw >ただ、padding領域を使えばある程度までならメタデータブロックのみの再配置で済む なるほど、PADDING領域かぁ、もしやったとしてもPADDINGをどれだけとるかの兼ね合いが難しそぉな気が。 >まあ、サンプル数が未知のPCMストリームをseektable付きで圧縮するという需要がどれだけあるか、だけど。 そもそも需要がほとんどなさそぉですねw http://egg.5ch.net/test/read.cgi/software/1219683003/63
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 939 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.018s