[過去ﾛｸﾞ] 音声可逆変換ソフト総合スレ (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
31(3): 2008/10/01(水)08:42 ID:Dhh56TnJ0(2/2) AAS
urlはスレ違なので無視しして下さい・・・
32(2): 2008/10/01(水)12:45 ID:2POb/yOD0(1/2) AAS
自前のwavファイル(24bit 96kHz 2ch 2:03:06 3.96 GB (4,254,562,124 バイト))
をflacへエンコードしようとしたのですが、作成されたflacのサイズが2.00 GB (2,147,498,063 バイト)でエラーになります。
foobar2000、flacDrop、FLAC frontendあたりを試しました。
FLAC 1.1.3でLarge file (>2GB) support everywhere
とあったので作成できるのでは？と思っているのですが、何か特別なコマンドライン等はあるのでしょうか？
flacのバージョンは1.2.1bで、念のためOSはXPのSP3です。
foobar2000でのエラーメッセージは下記のとおりです。
An error occured while writing to file (The encoder has terminated prematurely with code 1; please re-check parameters) : "a.flac"
Additional information:
Encoder stream format: 96000Hz / 2ch / 24bps
省2
33(5): 2008/10/01(水)12:54 ID:89WsoUBc0(1) AAS
たぶんwindows環境では2GB止まりなんじゃない
処理系のFILEとかoff_tの定義とか次第だと思う
WavPackも試してみたら?
34(1): 2008/10/01(水)18:55 ID:2POb/yOD0(2/2) AAS
>>33
即レスありがとうございます。
内容は全く追ってませんが、ちとソースを覗いてみたところ、
#if _MSC_VER <= 1600 /* @@@ [2G limit] */とコメントもあったので、
お話にあったとおりWin環境ぢゃ厳しいのかもしれないです。
ちなみに、VCぢゃなくってICLでコンパイルしたものなら……って試してみても同じでした。
takでは前にエンコードしているのですが、-ihsコマンドを付加しPIPEで処理すればエンコード可能で、
(たしか-ihsをつけないと2GB以上はエラーになった気がしました)
WavPackでは先ほど試したところ問題なくエンコードは可能、
Monkey's Audioは即エラーとなりました。
省1
35(8): 2008/10/01(水)22:55 ID:7k+DanR00(1) AAS
#if _MSC_VER <= 1600 /* @@@ [2G limit] */とコメントもあったので、
これに引っかかるコンパイラって、いつの時代の VC だよｗ
アプリの方が 2G 超えるファイルを扱えないか、
保存先に指定しているドライブが、FAT32 なんだろう。
ためしに Lilith で変換してみたら、
2.5GB の FLAC ファイル作れたので、
FLAC がサポートしていないわけではない。
環境見直してみなさい。
36(4): 2008/10/02(木)04:47 ID:RKymDEoc0(1/2) AAS
>>35
こんな時間にすみません。
2Gで検索かけてコメントの2G Limitしかみてなかったｗ
相変わらずその先の処理もまだみてませんが。
ソースのwavファイルの位置、flac.exeの位置、保存先はNTFSでしたが、
Lilithで変換したらあっさりできました。
アプリの方が〜ってありましたので念のためGUIアプリを使わず、
コマンドラインからも変換を試みましたがやはり2GBでエラーになりました。
まぁ、そっちの理由は解りませんが、何はともあれ変換できました。
本当にありがとうございます。
37(2): 2008/10/02(木)05:05 ID:CJRFS13e0(1/3) AAS
libFLAC自体にに2GB制限は無いけど
フロントエンドの実装がwinだとNGってことか
38(2): 2008/10/02(木)13:19 ID:51IeJvMA0(1) AAS
コマンドラインでも落ちるってことは、GUIは無関係で環境のせいじゃないかな。
アホなウイルスソフトが2GBのファイルまでしか処理できなくて勝手に落とすとか。
39(2): 35 2008/10/02(木)14:50 ID:IqmyHboz0(1) AAS
>>36-37
ソースは見ていないが、コマンドラインプログラムの方は、
標準 C 関数のみで書かれているだろうから、
そっちの方のファイル入出力関数の制限で 2G までかと。
標準 C 関数は、ものすごく古い時代に作成されたものだから、
ファイルサイズとかは int 型 が使われていて、
32bit OS なら 32bitのサイズ。32bit 符号付きだと、
最大値がちょうど2Gになる。(厳密には 2G -1)
64bit OS でコンパイルすれば、int 型は 64bit になるはずなので、
2GB を超えるサイズを扱えるようになる。
省7
40(3): 2008/10/02(木)17:16 ID:CJRFS13e0(2/3) AAS
>標準 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というのもこれ。
41(1): ８ 2008/10/02(木)21:39 ID:FwRQGWqv0(1) AAS
すげえ良スレだな、いいぞおまえら、つづけろ
42(1): 2008/10/02(木)21:44 ID:RKymDEoc0(2/2) AAS
>>38
もともとGUIツールは引数をflac.exeに渡す位と思っていたので、念のため〜やはり〜と書かせていただきました。
takやらWavPackやらLilithで変換ができるのに、
何故flac.exeだけ2GBまでしか処理できず落とされるのか見当もつきませんがとりあえず環境みてみます。
>>39-40
型によってひっかかるのではないかというのは解りましたが、ファイルサイズになんで符号付きのintなんでしょ？
wavは確かunsigned longで4GBまでいけるのに……。
自分の中では、変換自体はWinでもできたので>>37氏の言う通りなのかなぁとは思っております。
まぁ、うちの環境がおかしいだけなのかもしれませんが、
>>35氏のLilithの件以外では、できてる、とかできない等の話も訊かないので。
省11
43(2): 2008/10/02(木)22:00 ID:CJRFS13e0(3/3) AAS
>>42
>ファイルサイズになんで符号付きのintなんでしょ
ファイルサイズというかoff_tはオフセットで相対位置を示す時にも使うから。
fsseko(fp,-1,SEEK_CUR)とかね
seektableの有無はmetaflac --list hoge.flacで確認可能。
44(3): 2008/10/03(金)04:45 ID:5mcTPKC50(1) AAS
>>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は存在してませんでした。
省4
45(3): 35 2008/10/03(金)23:23 ID:Gk/CpB0M0(1) AAS
>>44
Lilith は、もしかしてオンラインアップデートしていないバージョンを使ってる？
0.992 にアップデートすると、FLAC 1.2.1 が使われてる。
これ最新のFLACのライブラリのはずだよね。
ところで、以前の flac.exe (公式のコマンドラインプログラム)では、
余計な SeekTable を作成するという不具合があったけど、
今のは直ってるのかしら？
たしか、曲長にかかわらず、100個だか1000個だか作成しちゃうっての。
短い曲のときは無駄だし、長い曲のときは数足りず、で
まともに機能しないケースが存在すると指摘されてたような。
省8
46: 2008/10/03(金)23:24 ID:B97GWqQQ0(1) AAS
flac tgfでデフォルトの圧縮率や保存先が設定できず、いちいち設定->バッチ
とやるのが苦痛なのですが、もっとマシなフロントエンドはないですか？
47(5): 2008/10/03(金)23:53 ID:zbHi8B7I0(1) AAS
>>45
fseekで2GB以上のファイルを扱うのはLP64とかILP64な処理系じゃないと無理でしょ。
fseekoみたいにoff_tじゃなくてlongだから。
>余計な SeekTable を作成するという不具合
それってfoobar2000のpipe encoderがwavのヘッダに
適当なdataチャンクの大きさを書くのが原因のやつじゃないの?
1.2.0で--ignore-chunk-sizesが追加されてるけど、
これを付けるとそもそもseektableが作られなくなる。
48(2): 35 2008/10/04(土)01:31 ID:FD/w9THf0(1) AAS
>>47
いえ、flac.exe 本体のバグ(?) です。
かなり昔の話だけど、確か Lilith の HP で見た気がしたので、
作者の書き込みかと思ってたら、ユーザの人の書き込みだったみたい。
外部ﾘﾝｸ[cgi]:www.project9k.jp
2ch からは直リンできないんだったかな？
みれなかったらURLコピペでよろすく
49(3): 2008/10/04(土)01:55 ID:L6+WXtUj0(1/3) AAS
>>48
いや、それだとどうやってflac.exeを使ったかが分からないから
wavヘッダのサンプル数が間違っている可能性は捨てきれないと思うけど。
サンプル数を越えたところにまで空のseekpointを作成というのは
まさにその問題の典型だし。
50(2): 2008/10/04(土)12:09 ID:M36DJN+M0(1/3) AAS
>>45,47-49
LilithのVerの件ですが、ご指摘のとおり0.9.9.2にアップデートでlibFLAC 1.2.1になりました。
度々ホントありがとうございます。
一度オンラインアップデートしたんだけどなぁｗ
SeekTableの件につきましては、
foobarというかPIPE処理等で事前にサンプル数が取得できない際におこるようです。
Seek Point計算はサンプル数が必須で、
例えば録音しながらPIPEで変換等は問題がでそうと考えます(サンプル数渡してもダミーだろぉし)
外部ﾘﾝｸ[cgi]:www.project9k.jp
その後の1217で投稿した方もエンコード方法を認めております。
省16
51(4): 2008/10/04(土)13:56 ID:YQPA4Ds60(1) AAS
>>50
レポート乙
52(3): 2008/10/04(土)14:48 ID:L6+WXtUj0(2/3) AAS
>>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を付加するよ。
53(1): 2008/10/04(土)18:23 ID:M36DJN+M0(2/3) AAS
>>51
や、いつも長ったらしくてホントゴメンよぉ……、今回も長いけどｗ
>>52
>FLACはseektable無しでもシーク可能。seektableはシークを高速にするためにある。
PIPEでファイル作成できない、もしくは他のエンコーダに劣るという訳ではなく、
PIPEによってFLACの特徴を一つ失うとなるならば、むいてるとは言えないのかなと。
PIPEを使わずにSeekTableありで変換できるのならばそちらを選ぶでしょうし。
>FLAC__stream_encoder_set_compression_levelを使ってないのが原因
frame samplesの違いは試してた際に特に気になっておりました。ありがとうございます。
>今のFLACのフロントエンドはデフォルトで8192bytesのpaddingを付加するよ。
省3
54(2): 2008/10/04(土)18:58 ID:M36DJN+M0(3/3) AAS
あー、わざと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 バイト)
〜前略〜
省11
55(4): 2008/10/04(土)19:47 ID:L6+WXtUj0(3/3) AAS
>>53
別にパイプだと必ずダメと言う訳じゃないよ。
普通にシェルからcat hoge.wav | flac - -o hoge.flacとかやる分には何の問題もない訳で。
サンプル数が既知なのに、わざわざパイプで渡す時に
チャンクサイズを不定にして渡すから問題になる。
だから47ではflacではなくfoobar側の問題という書き方をした訳だが。
スレ違いだがLAME 3.98のTLENタグなんかでも同じ問題が起こるはず。
56(2): 2008/10/05(日)06:00 ID:aBfFvcZR0(1) AAS
>>55
こんな時間ですみません。
>別にパイプだと必ずダメと言う訳じゃないよ。
ソレは実は解ってはいたんですが、変換元がwavファイルから渡すと確定していたり、
サンプル数が確定している場合がPIPE処理を使う前提の場合だと少ないのかなぁと思った訳です。
変換時に一時ファイルを作成したり、サンプル数が確定しているwavからの入力しかないと解るならば、
PIPE処理の必要性はあまりない気もしたので。
>LAME 3.98のTLENタグ
どぉやら似たよぉな感ぢですね、ちと色々みてみます。
ホントにご丁寧にありがとうございます。
57(1): 2008/10/05(日)16:25 ID:dwFW1c500(1) AAS
PCDJとバックアップの為に音源をアナログからPCに取り込もうと思ってここ来たが、
PCDJ用途と考えると展開速度が速いFLACが良いのかな
勉強になる
58(2): 2008/10/05(日)16:37 ID:IWv8Vcfq0(1) AAS
まあ、PIPE入力だと元がファイルではなくて終わりが決まっていないストリームの場合もあるから
エンコーダ側ではサンプル数を当てにした処理は避けうるなら避けたほうがいいのかも。
その辺はフォーマットのファイル設計なんかも関わってくるよね。
59(4): 2008/10/05(日)17:30 ID:Tg7yoQeF0(1) AAS
FLACの場合はメタデータブロックがファイルの先頭(圧縮データより前)にあるから、
seektableを作る場合、圧縮前にあらかじめseekpointの数だけ領域を確保する。
この操作のためにサンプル数が事前に必要。
ちなみに何サンプル目にseekpointを置くかを決めればいいだけなので、
サンプル数はおおよそでOKで正確である必要はない。
エンコード後に実際のサンプル数を使ってseektableを更新できるのが理想だけど、
確保した領域の分よりも多くのseekpointが必要な場合、
メタデータブロック後の巨大な圧縮データを再配置する必要がある。
ただ、padding領域を使えばある程度までならメタデータブロックのみの再配置で済むから
この程度の実装なら将来のFLACでやるかもしれない。
省1
60(3): 2008/10/06(月)00:21 ID:+Ew7Qu3h0(1/2) AAS
ごめんマニアックだけど
普通のWAV（CD音質＝44100Hz）以外のWAVでも対応してるのってありますか
DTMしてるんで24Bit/48ｋHzで保存してたりするもんで。
上下前次1-新書関写板覧索設栞歴
あと 942 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.269s*