[過去ﾛｸﾞ]
音声可逆変換ソフト総合スレ (1002ﾚｽ)
音声可逆変換ソフト総合スレ http://egg.5ch.net/test/read.cgi/software/1219683003/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
39: 35 [sage] 2008/10/02(木) 14:50:01 ID:IqmyHboz0 >>36-37 ソースは見ていないが、コマンドラインプログラムの方は、 標準 C 関数のみで書かれているだろうから、 そっちの方のファイル入出力関数の制限で 2G までかと。 標準 C 関数は、ものすごく古い時代に作成されたものだから、 ファイルサイズとかは int 型 が使われていて、 32bit OS なら 32bitのサイズ。32bit 符号付きだと、 最大値がちょうど2Gになる。(厳密には 2G -1) 64bit OS でコンパイルすれば、int 型は 64bit になるはずなので、 2GB を超えるサイズを扱えるようになる。 最近では、32 bit OS 用でも、64bit int への拡張版の C 関数互換のファイル入出力が用意されている場合が多いが、 環境ごと(コンパイラごと)に、実装内容が違うため、 こういうクロスプラットフォームなプロジェクトでは使用されない場合が多い。 しかし、foobar で2G 越え扱えないのはすごく意外だなぁ。 もしかして、flac は、CLI encoder だったりするのかしら？ built-in プラグインなら別なのかな？ http://egg.5ch.net/test/read.cgi/software/1219683003/39
40: 名無しさん＠お腹いっぱい。 [sage] 2008/10/02(木) 17:16:12 ID:CJRFS13e0 >標準 C 関数は、ものすごく古い時代に作成されたものだから、 >ファイルサイズとかは int 型 が使われていて、 処理系依存だよ。例えばLinuxはデフォルトだとoff_tはint32だが、 コンパイル時に_FILE_OFFSET_BITSマクロを64に定義するとint64になる。 OSXではデフォルトでoff_tがint64。 このあたりの違いはconfigureがよきにはからってくれる。 off_tがint64な処理系なら、基本的にstdioのfread/fwrite/fseekoだけで 問題なく2GB制限を突破できる。FLACのlarge file supportというのもこれ。 http://egg.5ch.net/test/read.cgi/software/1219683003/40
41: ８ [sage] 2008/10/02(木) 21:39:20 ID:FwRQGWqv0 すげえ良スレだな、いいぞおまえら、つづけろ http://egg.5ch.net/test/read.cgi/software/1219683003/41
42: 名無しさん＠お腹いっぱい。 [sage] 2008/10/02(木) 21:44:17 ID:RKymDEoc0 >>38 もともとGUIツールは引数をflac.exeに渡す位と思っていたので、念のため〜やはり〜と書かせていただきました。 takやらWavPackやらLilithで変換ができるのに、 何故flac.exeだけ2GBまでしか処理できず落とされるのか見当もつきませんがとりあえず環境みてみます。 >>39-40 型によってひっかかるのではないかというのは解りましたが、ファイルサイズになんで符号付きのintなんでしょ？ wavは確かunsigned longで4GBまでいけるのに……。 自分の中では、変換自体はWinでもできたので>>37氏の言う通りなのかなぁとは思っております。 まぁ、うちの環境がおかしいだけなのかもしれませんが、 >>35氏のLilithの件以外では、できてる、とかできない等の話も訊かないので。 ちなみに、foobarについてなのですが、ご推測の通りで、 最近のは専用のプラグインが入っておらずCLI encoderだったりします。 >>32のエラーメッセージでCommand lineとある通りです。 0.9.x系でflacエンコーダのコンポーネントってあるのかな？と思ったトコロで思い出したのですが、 0.8.3ではfoo_flaccer.dll(libFLAC 1.1.2)があり、foo_flaccer.dll経由でのエンコードはできました。 ただ、wikiによるとfoo_flaccerにはseektableを付加しないようですが。 ちなみにLilithで変換したのはlibFLAC 1.1.1だったけど、コレは問題ないのかな？ レスくださった方々ありがとうございました。 当初のもくろみでは つコマンドラインオプション みたいな感ぢで話題が終わると思っていたのだがｗ http://egg.5ch.net/test/read.cgi/software/1219683003/42
43: 名無しさん＠お腹いっぱい。 [sage] 2008/10/02(木) 22:00:18 ID:CJRFS13e0 >>42 >ファイルサイズになんで符号付きのintなんでしょ ファイルサイズというかoff_tはオフセットで相対位置を示す時にも使うから。 fsseko(fp,-1,SEEK_CUR)とかね seektableの有無はmetaflac --list hoge.flacで確認可能。 http://egg.5ch.net/test/read.cgi/software/1219683003/43
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になりました。 度々ホントありがとうございます。 一度オンラインアップデートしたんだけどなぁｗ 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 や、いつも長ったらしくてホントゴメンよぉ……、今回も長いけどｗ >>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
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 944 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.022s