08/10/02 22:00:18 CJRFS13e0
>>42
>ファイルサイズになんで符号付きのintなんでしょ
ファイルサイズというかoff_tはオフセットで相対位置を示す時にも使うから。
fsseko(fp,-1,SEEK_CUR)とかね
seektableの有無はmetaflac --list hoge.flacで確認可能。
44:名無しさん＠お腹いっぱい。
08/10/03 04:45:00 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でエンコードできるソフトでも探してみようと思います。
ホントにご丁寧にありがとうございました。
45:35
08/10/03 23:23:50 Gk/CpB0M0
>>44
Lilith は、もしかしてオンラインアップデートしていないバージョンを使ってる？
0.992 にアップデートすると、FLAC 1.2.1 が使われてる。
これ最新のFLACのライブラリのはずだよね。
ところで、以前の flac.exe (公式のコマンドラインプログラム)では、
余計な SeekTable を作成するという不具合があったけど、
今のは直ってるのかしら？
たしか、曲長にかかわらず、100個だか1000個だか作成しちゃうっての。
短い曲のときは無駄だし、長い曲のときは数足りず、で
まともに機能しないケースが存在すると指摘されてたような。
>>40
処理系＝コンパイラと捉えるなら、処理系と書いた方がよかったかもね。
Win みたいに複数のコンパイラが用意されている場合、
それぞれで制限違ったりするので。
VC の場合、少なくとも 2008 では、_fseeki64 とか用意されている以上、
通常の fseek とかで 2GB 以上を扱えるようには出来ないんだろうな。
関数自体は、define で置き換えればよいわけだが、
データを保持する変数の型のほう変更するのが面倒そうだ
46:名無しさん＠お腹いっぱい。
08/10/03 23:24:08 B97GWqQQ0
flac tgfでデフォルトの圧縮率や保存先が設定できず、いちいち設定->バッチ
とやるのが苦痛なのですが、もっとマシなフロントエンドはないですか？
47:名無しさん＠お腹いっぱい。
08/10/03 23:53:13 zbHi8B7I0
>>45
fseekで2GB以上のファイルを扱うのはLP64とかILP64な処理系じゃないと無理でしょ。
fseekoみたいにoff_tじゃなくてlongだから。
>余計な SeekTable を作成するという不具合
それってfoobar2000のpipe encoderがwavのヘッダに
適当なdataチャンクの大きさを書くのが原因のやつじゃないの?
1.2.0で--ignore-chunk-sizesが追加されてるけど、
これを付けるとそもそもseektableが作られなくなる。
48:35
08/10/04 01:31:59 FD/w9THf0
>>47
いえ、flac.exe 本体のバグ(?) です。
かなり昔の話だけど、確か Lilith の HP で見た気がしたので、
作者の書き込みかと思ってたら、ユーザの人の書き込みだったみたい。
URLﾘﾝｸ(www.project9k.jp)
2ch からは直リンできないんだったかな？
みれなかったらURLコピペでよろすく
49:名無しさん＠お腹いっぱい。
08/10/04 01:55:54 L6+WXtUj0
>>48
いや、それだとどうやってflac.exeを使ったかが分からないから
wavヘッダのサンプル数が間違っている可能性は捨てきれないと思うけど。
サンプル数を越えたところにまで空のseekpointを作成というのは
まさにその問題の典型だし。
50:名無しさん＠お腹いっぱい。
08/10/04 12:09:03 M36DJN+M0
>>45,47-49
LilithのVerの件ですが、ご指摘のとおり0.9.9.2にアップデートでlibFLAC 1.2.1になりました。
度々ホントありがとうございます。
一度オンラインアップデートしたんだけどなぁｗ
SeekTableの件につきましては、
foobarというかPIPE処理等で事前にサンプル数が取得できない際におこるようです。
Seek Point計算はサンプル数が必須で、
例えば録音しながらPIPEで変換等は問題がでそうと考えます(サンプル数渡してもダミーだろぉし)
URLﾘﾝｸ(www.project9k.jp)
その後の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で見分けているので関係ないだろぉと推測して、違いはコレ位のようです。
51:名無しさん＠お腹いっぱい。
08/10/04 13:56:24 YQPA4Ds60
>>50
レポート乙
52:名無しさん＠お腹いっぱい。
08/10/04 14:48:29 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を付加するよ。
53:名無しさん＠お腹いっぱい。
08/10/04 18:23:19 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に確認しております。
ホントご丁寧にレスありがとうございました。
54:名無しさん＠お腹いっぱい。
08/10/04 18:58:08 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のみの変化でした。
あくまでうちの場合はですが。
55:名無しさん＠お腹いっぱい。
08/10/04 19:47:00 L6+WXtUj0
>>53
別にパイプだと必ずダメと言う訳じゃないよ。
普通にシェルからcat hoge.wav | flac - -o hoge.flacとかやる分には何の問題もない訳で。
サンプル数が既知なのに、わざわざパイプで渡す時に
チャンクサイズを不定にして渡すから問題になる。
だから47ではflacではなくfoobar側の問題という書き方をした訳だが。
スレ違いだがLAME 3.98のTLENタグなんかでも同じ問題が起こるはず。
56:名無しさん＠お腹いっぱい。
08/10/05 06:00:45 aBfFvcZR0
>>55
こんな時間ですみません。
>別にパイプだと必ずダメと言う訳じゃないよ。
ソレは実は解ってはいたんですが、変換元がwavファイルから渡すと確定していたり、
サンプル数が確定している場合がPIPE処理を使う前提の場合だと少ないのかなぁと思った訳です。
変換時に一時ファイルを作成したり、サンプル数が確定しているwavからの入力しかないと解るならば、
PIPE処理の必要性はあまりない気もしたので。
>LAME 3.98のTLENタグ
どぉやら似たよぉな感ぢですね、ちと色々みてみます。
ホントにご丁寧にありがとうございます。
57:名無しさん＠お腹いっぱい。
08/10/05 16:25:07 dwFW1c500
PCDJとバックアップの為に音源をアナログからPCに取り込もうと思ってここ来たが、
PCDJ用途と考えると展開速度が速いFLACが良いのかな
勉強になる
58:名無しさん＠お腹いっぱい。
08/10/05 16:37:50 IWv8Vcfq0
まあ、PIPE入力だと元がファイルではなくて終わりが決まっていないストリームの場合もあるから
エンコーダ側ではサンプル数を当てにした処理は避けうるなら避けたほうがいいのかも。
その辺はフォーマットのファイル設計なんかも関わってくるよね。
59:名無しさん＠お腹いっぱい。
08/10/05 17:30:58 Tg7yoQeF0
FLACの場合はメタデータブロックがファイルの先頭(圧縮データより前)にあるから、
seektableを作る場合、圧縮前にあらかじめseekpointの数だけ領域を確保する。
この操作のためにサンプル数が事前に必要。
ちなみに何サンプル目にseekpointを置くかを決めればいいだけなので、
サンプル数はおおよそでOKで正確である必要はない。
エンコード後に実際のサンプル数を使ってseektableを更新できるのが理想だけど、
確保した領域の分よりも多くのseekpointが必要な場合、
メタデータブロック後の巨大な圧縮データを再配置する必要がある。
ただ、padding領域を使えばある程度までならメタデータブロックのみの再配置で済むから
この程度の実装なら将来のFLACでやるかもしれない。
まあ、サンプル数が未知のPCMストリームをseektable付きで圧縮するという需要がどれだけあるか、だけど。
60:名無しさん＠お腹いっぱい。
08/10/06 00:21:50 +Ew7Qu3h0
ごめんマニアックだけど
普通のWAV（CD音質＝44100Hz）以外のWAVでも対応してるのってありますか
DTMしてるんで24Bit/48ｋHzで保存してたりするもんで。
61:名無しさん＠お腹いっぱい。
08/10/06 00:31:25 lIkuJkQR0
>>60
FLAC, WavPack, etc
URLﾘﾝｸ(en.wikipedia.org)
62:名無しさん＠お腹いっぱい。
08/10/06 00:43:36 +Ew7Qu3h0
>>61
海よりも深くThx
63:名無しさん＠お腹いっぱい。
08/10/06 12:26:29 K/cRAG+O0
>>58
うちもそんな感ぢで考えてました。
入力元がファイルで長さが決まっているならば別フォーマットから変換でも簡単にwavのサンプル数割り出せるぢゃんってのは、
書いた後直ぐに気づいたのですが///
>>59
>FLACの場合は
詳細な説明ありがとうございます。
>サンプル数はおおよそでOKで
ってのが意外に感ぢしたが、きちんとchunkSizeを渡してなかった時もSeekTableを作ってはいたのに気づくべきでした。
ちと、foobarがstreamでなくファイルも何故サンプル数をきちんと渡していないか考えてみたのですが、
複数のファイルを選択し単一のファイルとして変換したり、未知の形式に対応する際に、
ファイルサイズでfoobar側がボトルネックになる可能性を排除しPIPEでエンコーダに渡し、
デコード後4GB以上のファイルでwavヘッダのchunkSizeが4byteを超える可能性も考え、計算することを避けたのかなぁと。
streamを扱う際と同等の処理でできるという方が強いのかもしれませんがｗ
>ただ、padding領域を使えばある程度までならメタデータブロックのみの再配置で済む
なるほど、PADDING領域かぁ、もしやったとしてもPADDINGをどれだけとるかの兼ね合いが難しそぉな気が。
>まあ、サンプル数が未知のPCMストリームをseektable付きで圧縮するという需要がどれだけあるか、だけど。
そもそも需要がほとんどなさそぉですねｗ
64:名無しさん＠お腹いっぱい。
08/10/10 20:56:02 KUhZ1k0h0
保守
65:名無しさん＠お腹いっぱい。
08/10/11 22:42:24 PdZtDwEJ0
WMA可逆圧縮で保存したものをMP3に変えたいんだけど、どうやったらできるんですか？
66:名無しさん＠お腹いっぱい。
08/10/11 23:56:11 idxHXN7i0
dbPowerAmpでも使えばいいだろ
67:名無しさん＠お腹いっぱい。
08/10/12 00:38:18 kYgxBhjw0
foober2000も簡単ですよ^^
68:名無しさん＠お腹いっぱい。
08/10/12 00:38:58 8+Bg3UiB0
QMPも簡単ですよ^^
69:名無しさん＠お腹いっぱい。
08/10/12 08:39:05 uXbZ2ojq0
みなさんありがとうございます。
foober2000をインストールしました。
コンバート→MP3（FAST)とすすみましたが、変換するファイル（WMA）を選択できませんなぜかわかりません。
教えてください。
70:名無しさん＠お腹いっぱい。
08/10/12 08:53:38 kYgxBhjw0
つfoober2000 wiki
URLﾘﾝｸ(foobar2000.xrea.jp)
71:名無しさん＠お腹いっぱい。
08/10/12 16:03:31 XVNEBbun0
>>61のwikipediaのだとALACが44.1/48kHzのみになっているが、
24bit 96kHzも変換、再生できるな
iPodに転送できるのは24bit 48kHzまでだけど
72:名無しさん＠お腹いっぱい。
08/10/18 08:36:28 oVCiH9z+0
takのcueシート埋め込みをコマンドラインだけでやりたいんだけどなに使えばいいかわからん。
takc.exe以外に必要なファイルってある？
73:名無しさん＠お腹いっぱい。
08/10/20 19:17:13 n+cLrsnW0
可逆関係ないし流れぶった切るけど
パナのソフト以外でVM1→wavもしくはmp3に変換できるソフトないですか？
ソフト名か誘導お願いします
74:名無しさん＠お腹いっぱい。
08/10/21 00:27:15 t13hgCYd0
>>72
遅レスですが、もぉ解決してるかなぁ？
tagはAPEv2なんで、コマンドラインからならば
wapetとかtag(TAG command line tagger)とかを使えば良いかと。
EACと組み合わせるのならば、うちはflacencodeを使ってますが。
75:名無しさん＠お腹いっぱい。
08/11/01 18:46:22 ebt51ePh0
codecじゃなくて変換ソフトのスレなのか？
76:名無しさん＠お腹いっぱい。
08/11/01 18:51:29 d9NhvGpM0
そうとは限らないよ、一応
77:名無しさん＠お腹いっぱい。
08/11/05 00:26:04 aU/yy1fj0
音声可逆に関してはすべてを扱うと思って良いんじゃないか？
78:73
08/11/11 16:43:01 OdnrynTL0
自己解決しました。
79:名無しさん＠お腹いっぱい。
08/11/19 06:15:37 QTYg+GaU0
Linuxマシンが増えたのでttaからflacに乗り換えた
パソコンで聞く分には負荷の違いは分からんなぁ
機材に金あまりかけてないのもあるけど
圧縮速度は実感できるほど遅くなった
iPodがネイティブでflacサポートしたら環境全部flacに統一できててｳﾏｰだけど
ALACがあるから無理だろうな･･･
80:名無しさん＠お腹いっぱい。
08/11/19 17:23:59 53DpW23M0
二つFLACな悪行三昧
81:名無しさん＠お腹いっぱい。
08/11/19 20:47:00 2mpxOv3k0
40にしてFlac
82:名無しさん＠お腹いっぱい。
08/11/23 21:51:47 DKKbxn790
TAKが404だな
83:名無しさん＠お腹いっぱい。
08/11/23 21:58:29 rA0uCagy0
ドメインの有効期限が切れたかな
まあ実質配布の大本はHAだからいいんじゃね
84:名無しさん＠お腹いっぱい。
08/11/23 22:06:57 DKKbxn790
あれ、もう復活してた
85:名無しさん＠お腹いっぱい。
08/11/23 22:15:28 rA0uCagy0
サーバのメンテナンスかw
86:名無しさん＠お腹いっぱい。
08/11/24 02:45:17 aZPuZFEk0
ドメインが切れたら名前解決できないから404すら返ってこない。
87:名無しさん＠お腹いっぱい。
08/11/24 03:06:52 lG2/cQep0
いやいや、そのドメインの管理会社の広告ページに飛ぶ場合が多いよ
88:名無しさん＠お腹いっぱい。
08/11/24 22:44:32 lG2/cQep0
自分のサーバでTAKを配布するために転送量の多いコースに乗り換えたから
繋がらなくなってたらしい。
89:名無しさん＠お腹いっぱい。
08/12/13 07:27:59 rnJERrwH0
age
90:名無しさん＠お腹いっぱい。
08/12/20 23:39:52 NVYfyXfp0
TAK 1.1.0 Beta release
URLﾘﾝｸ(www.hydrogenaudio.org)
既にbeta3になってます。