音声可逆変換ソフト総合スレ

1 ：2008/08/26 〜 最終レス ：2012/10/22

です

2 ：

ごめん、よくわからないけどこのスレ開いちゃったんだ・・・
許してくれる？？？？

3 ：

Monkey's Audio　http://www.monkeysaudio.com/
圧縮率と圧縮速度重視。オープンソース。
Flac　http://flac.sourceforge.net/
展開速度重視。オープンソース。
Wavpack　http://www.wavpack.com/
バランス型。非可逆圧縮との差分が作れる。オープンソース。
TTA　http://www.true-audio.com/
圧縮速度重視。オープンソース。
TAK　http://www.thbeck.de/Tak/Tak.html
圧縮率、圧縮速度、展開速度のバランスに最も優れる。Windowsのみ。
OptimFROG　http://www.losslessaudio.org/
圧縮率重視。Windows, Linux, Mac。
Shorten　http://etree.org/shnutils/shorten/
最古参。圧縮率は最低レベル。オープンソース。
MPEG-4 ALS　http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html
MPEG-4標準規格。一部オープンソース。
La　http://www.lossless-audio.com/
圧縮率最重視。速度は度外視。Windows, Linux。
LPAC　http://www.nue.tu-berlin.de/wer/liebchen/lpac.html
MPEG-4 ALSの前身。
Apple Lossless Audio　http://www.apple.com/jp/itunes/
Apple純正。
Windows Media Audio Lossless　http://www.microsoft.com/japan/windows/windowsmedia/9series/codecs/audio.aspx
Microsoft純正。

4 ：

>>3
以下に独自実装で対応しているffmpeg抜かさんでくれ。
TTA decoder
APE(Monkey's Audio) decoder
Shorten decoder
Wavpack decoder
FLAC enc/decoder
ALAC(Apple Lossless Audio Codec) enc/decoder
http://ffmpeg.mplayerhq.hu/

5 ：

>>4
Monkey's Audioスレにあったフォーマットまとめにコメントを加えただけなのでw
基本的にlibavcodecは車輪の再発明かライセンスの問題絡みでやってるだけだから
純正のを(使える環境なら)使った方がいいんだよね。
FLACエンコーダの実装に関しては作者が使わない方がいいとまで言ってる。
http://www.hydrogenaudio.org/forums/index.php?showtopic=45013&st=300&p=443961&#entry443961

6 ：

>>4に追加で
MLP/TrueHD decoder (encoderは開発中の模様)
>>5
えーと、flakeがffmpegのflacエンコーダを作った人が作ったffmpegのflacの非公式フロントエンドだっけか。
シークがおかしいってのはmuxer側の問題で、もう修正されてたと思うけど…。

7 ：

>>6
おかしいんじゃなくてFLACのメタデータブロックに格納されてるseektableがサポートされてない。
無くてもシークは可能なんだが、FLACの特徴である高速なシークの恩恵を享受できない。
今ソース見てみたけどデコーダ(これはflakeとは無関係)もseektableサポートしてないね。

8 ：

　　　　　　　,／‐　＼ ::::::::::::ヽ
　　　　　　, '　ｓ　　　 ＼::::::::::::i
　　　　　／"""''／ーﾅ-ｔ----|
.　　　　/ 　　,.‐　　 ⌒ 　　　／ﾍ
　　　　｛入｜(･)　　(･)　　　 ||||||| 　　／￣￣￣￣￣￣￣
　　　　　　｜⊂⌒◯-------9） 　＜ 　ウィルス、ゲットだぜ！
　　　　　　｜ |||||||||＿　　　　｜ 　　　＼＿＿＿＿＿＿＿
　　　　　　　＼ ﾍ＿／　＼　／￣`＼､
.　　　　　　　　＼、__ i⌒i／, -'"~ 　`ヽ､
　　　　　　　,.‐'´　　　i--i　　　　　　　　＼
　　　　　　　`〈ヽ, -'"~T 　ヽ、　, -'"　~ `ヽ、
　　　　　　　／　（￣　T　　　iヽ、__　　　　　＼.
　　　　　／　　　　（￣T　　　|　　　`ヽ、　　　　｝
　　　　く　　　　　　￣　`ヽ、/__　　　　　　　　/
　　　　／　`ヽ、／|　　　　　　　`ヽ、　＿＿ノ
　　　　　　　／　　|　　　　　　　　　　T

9 ：

比較
http://www.monkeysaudio.com/comparison.html
http://flac.sourceforge.net/comparison.html
http://www.true-audio.com/TTA_Lossless_Audio_Codec_-_Performance_Comparison

10 ：

>>9
定番が抜けてるぞw
http://www.synthetic-soul.co.uk/comparison/lossless/

11 ：

>>10
クスコ
なんでMonkey'sAudioのInsaneが抜けてるんだろう？

12 ：

関連スレ
Monkey's Audio　part4
http://pc11.2ch.net/test/read.cgi/software/1136974601/

13 ：

関連スレ
音声可逆変換ソフト総合スレ
http://pc11.2ch.net/test/read.cgi/cdr/1219666212/

14 ：

なんで可逆限定になったの？

15 ：

俺が知りたいから

16 ：

>>1
乙
>>14
非可逆まで入れたら収拾がつかないだろｊｋ

17 ：

今のところ圧縮率と速度でMonkey'sAudio
対応ハードの多さでFLAC
この2強という考えてOKだよね？

18 ：

まさかそうくるとは思わなかった
あとapeの速度は底辺

19 ：

>>17
WAVへの展開の速さ＝再生付加の軽さもダントツだよ＞flac
しかし可逆は非可逆よりも乱立してる感があるなぁ
いくつかまとまってほしい

20 ：

>>19
展開速度ってポータブルに載せるときぐらいしか重要じゃないよね
ape、flac、La、MPEG-4 ALS、applelossless ぐらいで十分かな？

21 ：

>>19
可逆圧縮は純粋な論理処理だから、プログラマにはそそられるんでしょうね。
心理音響モデルみたいな要素は、非可逆圧縮の場合は実装のキモだけど、
コーディング以外の手間と時間がかかりますしね。
可逆は無劣化でトランスコーディングできるので、どのフォーマットが残ってもいいですね。

22 ：

>>18
ape速いじゃないか。
FLACよりエンコードは速いぞ。

23 ：

takは速くてそれなりの圧縮率だぜ

24 ：

craving explolerと携帯動画変換君では、flvからmp4にする場合、
どちらの方が、音質、画質がいいのでしょうか

25 ：

eacがcue書き込みでwav,ape以外をサポートしてくれればapeを捨てられるのに。

26 ：

wavから他の形式に変換すればOK

27 ：

>>25
イミフ

28 ：

FILE "CDImage.ape" WAVEなcuesheetがそのまま焼けるってことだろう。
人にあげる時とかwavに戻さなくていいから楽ではあるな。

29 ：

flac、tak、wavpackでいつも悩むよ。
flac: 汎用性高、負荷低、tag editorでも扱いやすい。
tak: 性能良、だけど2chまででDVDから抜くときは使えないし、tag editor含めまだまだ発展途上。
wv: flacよりも圧縮率高だけど、汎用性や負荷が中途半端。
apeは負荷高いし、すぐ壊れるので使わない前提です。

30 ：

デメリットを書いてないflacを使えばいいんジャマイカ?
あえてデメリットを挙げるならその中で一番圧縮率が悪いってことだけども。
あと、個人サイトっぽいけどこんなのありました。
ttp://www7a.biglobe.ne.jp/~fortywinks/music5.htm

31 ：

urlはスレ違なので無視しして下さい・・・

32 ：

自前の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
Command line: "C:\flac.exe" -s --ignore-chunk-sizes -5 - -o "a.flac"
Working folder: E:\

33 ：

たぶんwindows環境では2GB止まりなんじゃない
処理系のFILEとかoff_tの定義とか次第だと思う
WavPackも試してみたら?

34 ：

>>33
即レスありがとうございます。
内容は全く追ってませんが、ちとソースを覗いてみたところ、
#if _MSC_VER <= 1600 /* @@@ [2G limit] */とコメントもあったので、
お話にあったとおりWin環境ぢゃ厳しいのかもしれないです。
ちなみに、VCぢゃなくってICLでコンパイルしたものなら……って試してみても同じでした。
takでは前にエンコードしているのですが、-ihsコマンドを付加しPIPEで処理すればエンコード可能で、
(たしか-ihsをつけないと2GB以上はエラーになった気がしました)
WavPackでは先ほど試したところ問題なくエンコードは可能、
Monkey's Audioは即エラーとなりました。
そのうちVMwareにでもLinux入れて試してみます。

35 ：

#if _MSC_VER <= 1600 /* @@@ [2G limit] */とコメントもあったので、
これに引っかかるコンパイラって、いつの時代の VC だよｗ
アプリの方が 2G 超えるファイルを扱えないか、
保存先に指定しているドライブが、FAT32　なんだろう。
ためしに Lilith で変換してみたら、
2.5GB の FLAC ファイル作れたので、
FLAC がサポートしていないわけではない。
環境見直してみなさい。

36 ：

>>35
こんな時間にすみません。
2Gで検索かけてコメントの2G Limitしかみてなかったｗ
相変わらずその先の処理もまだみてませんが。
ソースのwavファイルの位置、flac.exeの位置、保存先はNTFSでしたが、
Lilithで変換したらあっさりできました。
アプリの方が〜ってありましたので念のためGUIアプリを使わず、
コマンドラインからも変換を試みましたがやはり2GBでエラーになりました。
まぁ、そっちの理由は解りませんが、何はともあれ変換できました。
本当にありがとうございます。

37 ：

libFLAC自体にに2GB制限は無いけど
フロントエンドの実装がwinだとNGってことか

38 ：

コマンドラインでも落ちるってことは、GUIは無関係で環境のせいじゃないかな。
アホなウイルスソフトが2GBのファイルまでしか処理できなくて勝手に落とすとか。

39 ：

>>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 プラグインなら別なのかな？

40 ：

>標準 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 ：

すげえ良スレだな、いいぞおまえら、つづけろ

42 ：

>>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だったけど、コレは問題ないのかな？
レスくださった方々ありがとうございました。
当初のもくろみでは
つコマンドラインオプション
みたいな感ぢで話題が終わると思っていたのだがｗ

43 ：

>>42
>ファイルサイズになんで符号付きのintなんでしょ
ファイルサイズというかoff_tはオフセットで相対位置を示す時にも使うから。
fsseko(fp,-1,SEEK_CUR)とかね
seektableの有無はmetaflac --list hoge.flacで確認可能。

44 ：

>>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 ：

>>44
Lilith は、もしかしてオンラインアップデートしていないバージョンを使ってる？
0.992 にアップデートすると、FLAC 1.2.1 が使われてる。
これ最新のFLACのライブラリのはずだよね。
ところで、以前の flac.exe (公式のコマンドラインプログラム)では、
余計な SeekTable を作成するという不具合があったけど、
今のは直ってるのかしら？
たしか、曲長にかかわらず、100個だか1000個だか作成しちゃうっての。
短い曲のときは無駄だし、長い曲のときは数足りず、で
まともに機能しないケースが存在すると指摘されてたような。
>>40
処理系＝コンパイラと捉えるなら、処理系と書いた方がよかったかもね。
Win みたいに複数のコンパイラが用意されている場合、
それぞれで制限違ったりするので。
VC の場合、少なくとも 2008 では、_fseeki64 とか用意されている以上、
通常の fseek とかで 2GB 以上を扱えるようには出来ないんだろうな。
関数自体は、define で置き換えればよいわけだが、
データを保持する変数の型のほう変更するのが面倒そうだ

46 ：

flac tgfでデフォルトの圧縮率や保存先が設定できず、いちいち設定->バッチ
とやるのが苦痛なのですが、もっとマシなフロントエンドはないですか？

47 ：

>>45
fseekで2GB以上のファイルを扱うのはLP64とかILP64な処理系じゃないと無理でしょ。
fseekoみたいにoff_tじゃなくてlongだから。
>余計な SeekTable を作成するという不具合
それってfoobar2000のpipe encoderがwavのヘッダに
適当なdataチャンクの大きさを書くのが原因のやつじゃないの?
1.2.0で--ignore-chunk-sizesが追加されてるけど、
これを付けるとそもそもseektableが作られなくなる。

48 ：

>>47
いえ、flac.exe 本体のバグ(?) です。
かなり昔の話だけど、確か Lilith の HP で見た気がしたので、
作者の書き込みかと思ってたら、ユーザの人の書き込みだったみたい。
ttp://www.project9k.jp/cgi-bin/innovationbbs/bbs.cgi?mode=one&namber=1212
2ch からは直リンできないんだったかな？
みれなかったらURLコピペでよろすく

49 ：

>>48
いや、それだとどうやってflac.exeを使ったかが分からないから
wavヘッダのサンプル数が間違っている可能性は捨てきれないと思うけど。
サンプル数を越えたところにまで空のseekpointを作成というのは
まさにその問題の典型だし。

50 ：

>>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で見分けているので関係ないだろぉと推測して、違いはコレ位のようです。

51 ：

>>50
レポート乙

52 ：

>>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 ：

>>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 ：

あー、わざと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 ：

>>53
別にパイプだと必ずダメと言う訳じゃないよ。
普通にシェルからcat hoge.wav | flac - -o hoge.flacとかやる分には何の問題もない訳で。
サンプル数が既知なのに、わざわざパイプで渡す時に
チャンクサイズを不定にして渡すから問題になる。
だから47ではflacではなくfoobar側の問題という書き方をした訳だが。
スレ違いだがLAME 3.98のTLENタグなんかでも同じ問題が起こるはず。

56 ：

>>55
こんな時間ですみません。
>別にパイプだと必ずダメと言う訳じゃないよ。
ソレは実は解ってはいたんですが、変換元がwavファイルから渡すと確定していたり、
サンプル数が確定している場合がPIPE処理を使う前提の場合だと少ないのかなぁと思った訳です。
変換時に一時ファイルを作成したり、サンプル数が確定しているwavからの入力しかないと解るならば、
PIPE処理の必要性はあまりない気もしたので。
>LAME 3.98のTLENタグ
どぉやら似たよぉな感ぢですね、ちと色々みてみます。
ホントにご丁寧にありがとうございます。

57 ：

PCDJとバックアップの為に音源をアナログからPCに取り込もうと思ってここ来たが、
PCDJ用途と考えると展開速度が速いFLACが良いのかな
勉強になる

58 ：

まあ、PIPE入力だと元がファイルではなくて終わりが決まっていないストリームの場合もあるから
エンコーダ側ではサンプル数を当てにした処理は避けうるなら避けたほうがいいのかも。
その辺はフォーマットのファイル設計なんかも関わってくるよね。

59 ：

FLACの場合はメタデータブロックがファイルの先頭(圧縮データより前)にあるから、
seektableを作る場合、圧縮前にあらかじめseekpointの数だけ領域を確保する。
この操作のためにサンプル数が事前に必要。
ちなみに何サンプル目にseekpointを置くかを決めればいいだけなので、
サンプル数はおおよそでOKで正確である必要はない。
エンコード後に実際のサンプル数を使ってseektableを更新できるのが理想だけど、
確保した領域の分よりも多くのseekpointが必要な場合、
メタデータブロック後の巨大な圧縮データを再配置する必要がある。
ただ、padding領域を使えばある程度までならメタデータブロックのみの再配置で済むから
この程度の実装なら将来のFLACでやるかもしれない。
まあ、サンプル数が未知のPCMストリームをseektable付きで圧縮するという需要がどれだけあるか、だけど。

60 ：

ごめんマニアックだけど
普通のWAV（CD音質＝44100Hz）以外のWAVでも対応してるのってありますか
DTMしてるんで24Bit/48ｋHzで保存してたりするもんで。

61 ：

>>60
FLAC, WavPack, etc
http://en.wikipedia.org/wiki/Comparison_of_audio_codecs#Technical_details

62 ：

>>61
海よりも深くThx

63 ：

>>58
うちもそんな感ぢで考えてました。
入力元がファイルで長さが決まっているならば別フォーマットから変換でも簡単にwavのサンプル数割り出せるぢゃんってのは、
書いた後直ぐに気づいたのですが///
>>59
>FLACの場合は
詳細な説明ありがとうございます。
>サンプル数はおおよそでOKで
ってのが意外に感ぢしたが、きちんとchunkSizeを渡してなかった時もSeekTableを作ってはいたのに気づくべきでした。
ちと、foobarがstreamでなくファイルも何故サンプル数をきちんと渡していないか考えてみたのですが、
複数のファイルを選択し単一のファイルとして変換したり、未知の形式に対応する際に、
ファイルサイズでfoobar側がボトルネックになる可能性を排除しPIPEでエンコーダに渡し、
デコード後4GB以上のファイルでwavヘッダのchunkSizeが4byteを超える可能性も考え、計算することを避けたのかなぁと。
streamを扱う際と同等の処理でできるという方が強いのかもしれませんがｗ
>ただ、padding領域を使えばある程度までならメタデータブロックのみの再配置で済む
なるほど、PADDING領域かぁ、もしやったとしてもPADDINGをどれだけとるかの兼ね合いが難しそぉな気が。
>まあ、サンプル数が未知のPCMストリームをseektable付きで圧縮するという需要がどれだけあるか、だけど。
そもそも需要がほとんどなさそぉですねｗ

64 ：

保守

65 ：

WMA可逆圧縮で保存したものをMP3に変えたいんだけど、どうやったらできるんですか？

66 ：

dbPowerAmpでも使えばいいだろ

67 ：

foober2000も簡単ですよ^^

68 ：

QMPも簡単ですよ^^

69 ：

みなさんありがとうございます。
foober2000をインストールしました。
コンバート→MP3（FAST)とすすみましたが、変換するファイル（WMA）を選択できませんなぜかわかりません。
教えてください。

70 ：

つfoober2000 wiki
ttp://foobar2000.xrea.jp/

71 ：

>>61のwikipediaのだとALACが44.1/48kHzのみになっているが、
24bit 96kHzも変換、再生できるな
iPodに転送できるのは24bit 48kHzまでだけど

72 ：

takのcueシート埋め込みをコマンドラインだけでやりたいんだけどなに使えばいいかわからん。
takc.exe以外に必要なファイルってある？

73 ：

可逆関係ないし流れぶった切るけど
パナのソフト以外でVM1→wavもしくはmp3に変換できるソフトないですか？
ソフト名か誘導お願いします

74 ：

>>72
遅レスですが、もぉ解決してるかなぁ？
tagはAPEv2なんで、コマンドラインからならば
wapetとかtag(TAG command line tagger)とかを使えば良いかと。
EACと組み合わせるのならば、うちはflacencodeを使ってますが。

75 ：

codecじゃなくて変換ソフトのスレなのか？

76 ：

そうとは限らないよ、一応

77 ：

音声可逆に関してはすべてを扱うと思って良いんじゃないか？

78 ：

自己解決しました。

79 ：

Linuxマシンが増えたのでttaからflacに乗り換えた
パソコンで聞く分には負荷の違いは分からんなぁ
機材に金あまりかけてないのもあるけど
圧縮速度は実感できるほど遅くなった
iPodがネイティブでflacサポートしたら環境全部flacに統一できててｳﾏｰだけど
ALACがあるから無理だろうな･･･

80 ：

二つFLACな悪行三昧

81 ：

40にしてFlac

82 ：

TAKが404だな

83 ：

ドメインの有効期限が切れたかな
まあ実質配布の大本はHAだからいいんじゃね

84 ：

あれ、もう復活してた

85 ：

サーバのメンテナンスかw

86 ：

ドメインが切れたら名前解決できないから404すら返ってこない。

87 ：

いやいや、そのドメインの管理会社の広告ページに飛ぶ場合が多いよ

88 ：

自分のサーバでTAKを配布するために転送量の多いコースに乗り換えたから
繋がらなくなってたらしい。

89 ：

age

90 ：

TAK 1.1.0 Beta release
http://www.hydrogenaudio.org/forums/index.php?showtopic=68104
既にbeta3になってます。

91 ：

Monkey's Audio http://www.monkeysaudio.com/index.html
Version 4.02 (January 19, 2009)
1. NEW: Includes Directshow filter for decoding APE files in any DirectShow compatible player like Windows Media Player, Zoom, etc.
2. Fixed: Corrupt APE files could cause decoder crashes in rare cases.
3. Changed: Updated builder that gets better compression, making for a smaller download.

92 ：

Efficient WMA MP3 Converterと
Free Mp3 Wma Converterのどっちが
いいの？

93 ：

Monkey's Audio http://www.monkeysaudio.com/index.html
Version 4.03 (January 21, 2009)
1. Changed: Added a help link to the help menu to show the included help file.

94 ：

ところで Windows Mobile もしくは PocketPC で再生出来るのは flac ぐらい？

95 ：

cue埋め込みFLACを作りたいのですが、
今までのところどうしても曲名が欠けてしまいます。
アルバム名と曲の時間しか埋め込めません。
どうやったら、cueの内容を減らさずに埋め込んだFLACを作成できますか？

96 ：

omaをmp3に変換したいんだけど、HIMDRendererWinで変換してもファイルが壊れてるかんじで
だめだった
他になにかいいソフトない？ググるとCDexとかでてくるけどそんな機能ないじゃんか

97 ：

期待あげ

98 ：

自己解決しますた

99 ：

あげておこう

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【PMS】 PS3 Media Server 【DLNA】 part6 (388)
Fire File Copy Part11 (436)
Fire File Copy Part11 (436)
Proxomitron フィルター作成スレッド Part14 (623)
【ニコニコ】NNDD Part5【Mac対応】 (531)
Mozilla Firefox SS 晒しスレ Part6【ScreenShot】 (557)
--log9.info------------------
【大阪】ネップシスターズ応援スレ☆1【日本橋】 (544)
【NMB48】中川紘美応援スレ☆2【ひろりん】 (264)
放課後プリンセス☆2 (582)
【NMB48】厄介ヲタとTOを語るスレ7【隔離】 (266)
【福岡】LinQ リンク Part19【7月18日4thｼﾝｸﾞﾙ】 (985)
【HKT48】熊沢世莉奈 応援スレ♪02【がんばり〜ぬ】 (742)
【SKE48】磯原杏華☆12スレ【祝！１６歳！】 (498)
【NMB48】東郷青空応援スレ☆1【そら】 (316)
【HKT48】仲西彩佳応援スレ1【あやきゃんまん】 (828)
【HKT48】宮脇咲良応援スレPart3【さくら咲け】 (365)
【SKE48/AKB48】松井珠理奈☆応援スレ13【in露板】 (329)
【SKE48】山田みずほ応援スレ【5期生】 (929)
【元SKE48】中村優花ちゃん【一般人くんさん】 (448)
【HKT48】兒玉遥 応援スレ☆3.5【はるっぴ】 (383)
【SKE48】竹内舞応援スレPart2【チームE】 (884)
T！Pスレ (443)
--log55.com------------------
【LSRPG】メルクストーリア【メルスト】520GP
【SEGA】コトダマン　68文字目
けものフレンズアプリ総合 38匹目【あらーむ/ぱびりおん/ぱずるごっこ】
【チェンクロ】チェインクロニクル466chain
【ゆゆゆい】結城友奈は勇者である 花結いのきらめき Part268
【アルスト】アルケミアストーリー part71
【マギレコ】マギアレコード 魔法少女まどか☆マギカ外伝 950週目
Fate/Grand Order どんな質問にも全力で優しく答えるスレ Lv.76