[過去ﾛｸﾞ] 音声可逆変換ソフト総合スレ (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1(3): 2008/08/26(火)01:50 ID:S1f4gspJ0(1) AAS
です
2(3): 2008/08/26(火)02:22 ID:beofQXWh0(1) AAS
ごめん、よくわからないけどこのスレ開いちゃったんだ・・・
許してくれる？？？？
3(4): とりあえず 2008/08/26(火)02:30 ID:VpM/W4vK0(1/4) AAS
Monkey's Audio 外部ﾘﾝｸ:www.monkeysaudio.com
圧縮率と圧縮速度重視。オープンソース。
Flac 外部ﾘﾝｸ:flac.sourceforge.net
展開速度重視。オープンソース。
Wavpack 外部ﾘﾝｸ:www.wavpack.com
バランス型。非可逆圧縮との差分が作れる。オープンソース。
TTA 外部ﾘﾝｸ:www.true-audio.com
圧縮速度重視。オープンソース。
TAK 外部ﾘﾝｸ[html]:www.thbeck.de
圧縮率、圧縮速度、展開速度のバランスに最も優れる。Windowsのみ。
省14
4(3): 2008/08/26(火)02:56 ID:O25ptmL/0(1/2) AAS
>>3
以下に独自実装で対応しているffmpeg抜かさんでくれ。
TTA decoder
APE(Monkey's Audio) decoder
Shorten decoder
Wavpack decoder
FLAC enc/decoder
ALAC(Apple Lossless Audio Codec) enc/decoder
外部ﾘﾝｸ:ffmpeg.mplayerhq.hu
8(3): 2008/08/26(火)04:36 ID:81upYMGl0(1) AAS
AA省
9(4): 2008/08/26(火)04:41 ID:+UIMU6H80(1/3) AAS
比較
外部ﾘﾝｸ[html]:www.monkeysaudio.com
外部ﾘﾝｸ[html]:flac.sourceforge.net
外部ﾘﾝｸ:www.true-audio.com
10(7): 2008/08/26(火)04:43 ID:VpM/W4vK0(4/4) AAS
>>9
定番が抜けてるぞw
外部ﾘﾝｸ:www.synthetic-soul.co.uk
13(3): 2008/08/26(火)12:31 ID:uxvUhCQU0(1) AAS
関連スレ
音声可逆変換ソフト総合スレ
2chｽﾚ:cdr
14(5): 2008/08/27(水)12:49 ID:ts6gl6Gl0(1) AAS
なんで可逆限定になったの？
18(8): 2008/08/31(日)08:17 ID:5y34/LxpO携(1) AAS
まさかそうくるとは思わなかった
あとapeの速度は底辺
19(3): 2008/08/31(日)11:55 ID:/WYunfG90(1) AAS
>>17
WAVへの展開の速さ＝再生付加の軽さもダントツだよ＞flac
しかし可逆は非可逆よりも乱立してる感があるなぁ
いくつかまとまってほしい
20(4): 2008/09/01(月)20:53 ID:Hpf6eOVd0(1) AAS
>>19
展開速度ってポータブルに載せるときぐらいしか重要じゃないよね
ape、flac、La、MPEG-4 ALS、applelossless ぐらいで十分かな？
21(3): 2008/09/02(火)00:51 ID:W9g+jvmn0(1) AAS
>>19
可逆圧縮は純粋な論理処理だから、プログラマにはそそられるんでしょうね。
心理音響モデルみたいな要素は、非可逆圧縮の場合は実装のキモだけど、
コーディング以外の手間と時間がかかりますしね。
可逆は無劣化でトランスコーディングできるので、どのフォーマットが残ってもいいですね。
25(4): 2008/09/10(水)20:04 ID:SAB7gvn50(1) AAS
eacがcue書き込みでwav,ape以外をサポートしてくれればapeを捨てられるのに。
31(3): 2008/10/01(水)08:42 ID:Dhh56TnJ0(2/2) AAS
urlはスレ違なので無視しして下さい・・・
33(5): 2008/10/01(水)12:54 ID:89WsoUBc0(1) AAS
たぶんwindows環境では2GB止まりなんじゃない
処理系のFILEとかoff_tの定義とか次第だと思う
WavPackも試してみたら?
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でエラーになりました。
まぁ、そっちの理由は解りませんが、何はともあれ変換できました。
本当にありがとうございます。
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というのもこれ。
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
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が作られなくなる。
49(3): 2008/10/04(土)01:55 ID:L6+WXtUj0(1/3) AAS
>>48
いや、それだとどうやってflac.exeを使ったかが分からないから
wavヘッダのサンプル数が間違っている可能性は捨てきれないと思うけど。
サンプル数を越えたところにまで空のseekpointを作成というのは
まさにその問題の典型だし。
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を付加するよ。
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タグなんかでも同じ問題が起こるはず。
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で保存してたりするもんで。
61(4): 2008/10/06(月)00:31 ID:lIkuJkQR0(1) AAS
>>60
FLAC, WavPack, etc
外部ﾘﾝｸ:en.wikipedia.org
64(3): 2008/10/10(金)20:56 ID:KUhZ1k0h0(1) AAS
保守
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.059s