[過去ﾛｸﾞ]
音声可逆変換ソフト総合スレ (1002ﾚｽ)
音声可逆変換ソフト総合スレ http://egg.5ch.net/test/read.cgi/software/1219683003/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
33: 名無しさん＠お腹いっぱい。 [sage] 2008/10/01(水) 12:54:09 ID:89WsoUBc0 たぶんwindows環境では2GB止まりなんじゃない 処理系のFILEとかoff_tの定義とか次第だと思う WavPackも試してみたら? http://egg.5ch.net/test/read.cgi/software/1219683003/33
34: 名無しさん＠お腹いっぱい。 [sage] 2008/10/01(水) 18:55:10 ID:2POb/yOD0 >>33 即レスありがとうございます。 内容は全く追ってませんが、ちとソースを覗いてみたところ、 #if _MSC_VER <= 1600 /* @@@ [2G limit] */とコメントもあったので、 お話にあったとおりWin環境ぢゃ厳しいのかもしれないです。 ちなみに、VCぢゃなくってICLでコンパイルしたものなら……って試してみても同じでした。 takでは前にエンコードしているのですが、-ihsコマンドを付加しPIPEで処理すればエンコード可能で、 (たしか-ihsをつけないと2GB以上はエラーになった気がしました) WavPackでは先ほど試したところ問題なくエンコードは可能、 Monkey's Audioは即エラーとなりました。 そのうちVMwareにでもLinux入れて試してみます。 http://egg.5ch.net/test/read.cgi/software/1219683003/34
35: 名無しさん＠お腹いっぱい。 [sage] 2008/10/01(水) 22:55:03 ID:7k+DanR00 #if _MSC_VER <= 1600 /* @@@ [2G limit] */とコメントもあったので、 これに引っかかるコンパイラって、いつの時代の VC だよｗ アプリの方が 2G 超えるファイルを扱えないか、 保存先に指定しているドライブが、FAT32 なんだろう。 ためしに Lilith で変換してみたら、 2.5GB の FLAC ファイル作れたので、 FLAC がサポートしていないわけではない。 環境見直してみなさい。 http://egg.5ch.net/test/read.cgi/software/1219683003/35
36: 名無しさん＠お腹いっぱい。 [sage] 2008/10/02(木) 04:47:22 ID:RKymDEoc0 >>35 こんな時間にすみません。 2Gで検索かけてコメントの2G Limitしかみてなかったｗ 相変わらずその先の処理もまだみてませんが。 ソースのwavファイルの位置、flac.exeの位置、保存先はNTFSでしたが、 Lilithで変換したらあっさりできました。 アプリの方が〜ってありましたので念のためGUIアプリを使わず、 コマンドラインからも変換を試みましたがやはり2GBでエラーになりました。 まぁ、そっちの理由は解りませんが、何はともあれ変換できました。 本当にありがとうございます。 http://egg.5ch.net/test/read.cgi/software/1219683003/36
37: 名無しさん＠お腹いっぱい。 [sage] 2008/10/02(木) 05:05:53 ID:CJRFS13e0 libFLAC自体にに2GB制限は無いけど フロントエンドの実装がwinだとNGってことか http://egg.5ch.net/test/read.cgi/software/1219683003/37
38: 名無しさん＠お腹いっぱい。 [sage] 2008/10/02(木) 13:19:10 ID:51IeJvMA0 コマンドラインでも落ちるってことは、GUIは無関係で環境のせいじゃないかな。 アホなウイルスソフトが2GBのファイルまでしか処理できなくて勝手に落とすとか。 http://egg.5ch.net/test/read.cgi/software/1219683003/38
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
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 950 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.019s