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

**名無しさん＠お腹いっぱい。** · 2008/08/26(火) 01:50:03

です

**名無しさん＠お腹いっぱい。** · 2009/12/03(木) 04:12:42

>>183
http://www.hydrogenaudio.org/forums/index.php?showtopic=64628&st=0&p=656451&#entry656451

**名無しさん＠お腹いっぱい。** · 2009/12/05(土) 05:31:42

>>184
おお、出てるのか。

でも flac は圧縮率悪いからなあ・・・
どこまで行けるのだろうか？

**名無しさん＠お腹いっぱい。** · 2009/12/05(土) 14:20:58

え?
アルゴリズムの改善じゃないんだから、圧縮率は変わらんでしょ。

**名無しさん＠お腹いっぱい。** · 2009/12/05(土) 14:39:38

>>186
よく読んでないから、どういう理屈かわからんが
http://www.cuetools.net/lib/exe/fetch.php/flacudatest.jpg

**名無しさん＠お腹いっぱい。** · 2009/12/05(土) 15:06:42

CD一枚分の.wavファイルと、.cueシートを元に、市販のCDと同じイメージの、トラック分割されたCD-Rを作成したい場合、
EACのVer.99-5の日本語化板を使用した場合でも、.cueシートの.wavファイル名、アーチスト名、トラック名（曲名）が
全角文字で記述されていると、読み込んだ.cueシートのウィンドウで文字化けが発生してしまい先に進めません。
全角文字に対応した、EAC　Ver0.99-5日本語化板の代用になるソフトって、リリースされていないのでしょうか？

ここの皆さんは、「市販のCDと同じイメージの、トラック分割されたCD-Rを作成したい場合」にはどうしているのですか？

やっぱり拡張子を.cueから.txtの変更して、メモ帳で開いて、バックスペースで全角文字を消して半角英数に書き換えて、
上書き保存して.txtを.cueに戻す作業をしているんですか？

**名無しさん＠お腹いっぱい。** · 2009/12/05(土) 15:14:07

>>188
CD-Rを焼くソフトは何を使っているの？
バージョンとかも詳しくカキコしないとアドバイスのしようが無いよ。

**名無しさん＠お腹いっぱい。** · 2009/12/05(土) 15:19:17

EACで焼くって言ってるようだから、（連携版の）CDRDAOじゃないの？

**名無しさん＠お腹いっぱい。** · 2009/12/05(土) 15:38:40

>>187
まあ、FLACの仕様の範囲内でもLPC予測係数の導出を最適化する等の余地はあるから
flakeと同じようなことをしてるんだろうね

1%とかそういうオーダでの改善は難しいかと

**名無しさん＠お腹いっぱい。** · 2009/12/05(土) 16:12:24

>>189
.wavファイル名、曲名等が全角文字な.cueシートだとEAC Ver0.99-5では正常に読み込めない様ですので、
EAC以外に、全角文字を含む.cueシートに対応した、トラック分割できるCD-R焼きソフトがあれば教えて欲しいのです。
>>190
EAC内蔵のCD-R焼き機能には、CDRDAOという名前がついているんですか。知りませんでした。
いまEACを起動してみたのですが、「CDRDAO」という名前を確認できませんでした。

**名無しさん＠お腹いっぱい。** · 2009/12/06(日) 03:52:46

>>187
Laあたりでやったらおもしろいかもしれないがデコードで死ねるな

ポータブル機器に載せられる程度に出来ないのかな？

**名無しさん＠お腹いっぱい。** · 2009/12/06(日) 10:31:21

>>188
拡張子は.cueのままで
右クリックの「プログラムを開く」から、テキストエディタ（ノートパッド）を呼び出して開くか、
デスクトップにテキストエディタ（ノートパッド等）のショートカットを作って、そこにD&Dすれば楽でないかな

**194** · 2009/12/06(日) 10:33:06

ノートパッド＝メモ帳で

**194** · 2009/12/06(日) 10:49:43

あと、Mp3tag使ってみるのも良いんでないかい？

**名無しさん＠お腹いっぱい。** · 2009/12/16(水) 03:36:33

http://www.hydrogenaudio.org/forums/index.php?showtopic=76866

作者が利根川さん状態なのは相変わらずだが
今のTAKはFLACに成果が取り込まれるまでの核実験場ということになるのかね、これは

**名無しさん＠お腹いっぱい。** · 2009/12/18(金) 03:32:19

利根川さんって熱々鉄板土下座の人？

**名無しさん＠お腹いっぱい。** · 2009/12/19(土) 02:16:37

m4aへ変換できるフリーソフトウェアで
評判のよいものがあればお聞きしたいのですが。
おすすめはありますか？

**名無しさん＠お腹いっぱい。** · 2009/12/19(土) 02:22:25

このスレで聞くといくことはApple Lossless？
itunesがいやならffmpegしか選択肢がない

aacのことなら
【高音質】AACオーディオ総合4【mp4/m4a】
http://pc12.2ch.net/test/read.cgi/software/1226818269/

フロントエンドは好きなの使うといいよ

**名無しさん＠お腹いっぱい。** · 2009/12/28(月) 20:22:36

>>198
その人

**名無しさん＠お腹いっぱい。** · 2010/01/07(木) 15:04:13

http://www7a.biglobe.ne.jp/~fortywinks/music4.htm
ここのCD→TAK (TAKCでタグを付ける場合)の欄を参考にtakエンコードを試してるんだけど
何度やってもバラファイルができでしまう…
一続きのtakファイルにするにはどうしたらいいかな？

**名無しさん＠お腹いっぱい。** · 2010/01/09(土) 09:48:19

TAK 2.0 が出てたので入れてみた。
アルバム圧縮して前バージョンから
412.5M → 411.3M
さらに縮むようになった。

>>202 私は foobar2000 でやってます。

**名無しさん＠お腹いっぱい。** · 2010/01/09(土) 09:52:31

0.3%とか意味ねーｗ

**名無しさん＠お腹いっぱい。** · 2010/01/10(日) 21:38:51

むしろ速度とか、そっちはどうなんよｗ

**名無しさん＠お腹いっぱい。** · 2010/01/19(火) 17:36:31

>>176
v 0.0.1.4来てますね

**名無しさん＠お腹いっぱい。** · 2010/01/25(月) 09:21:02

つか ape の insane とか La じゃない限り速度はもう良いよ
CDを rip する方が時間かかるから

むしろ使い勝手と圧縮率が問題だ

**名無しさん＠お腹いっぱい。** · 2010/01/29(金) 08:53:15

HDDが安い今、圧縮率のほうがどうでもいいような

**名無しさん＠お腹いっぱい。** · 2010/01/29(金) 14:56:07

２Tを4機積みとか普通だからなぁ…
個人的には使い勝手と圧縮・展開速度

**名無しさん＠お腹いっぱい。** · 2010/01/29(金) 17:06:50

wav+cue最強

**名無しさん＠お腹いっぱい。** · 2010/01/29(金) 20:35:28

>>209
普通じゃねえよｗｗ

**名無しさん＠お腹いっぱい。** · 2010/01/31(日) 09:12:30

>>210
それだけはないｗ

**名無しさん＠お腹いっぱい。** · 2010/01/31(日) 20:26:50

>>212
仮想CDで使えるから最強だろ。
むしろFSの側で圧縮できないものか。

**名無しさん＠お腹いっぱい。** · 2010/01/31(日) 21:17:16

>>213
いや、タグやら、カバーやら色々使えないだろと･･cueが拡張されない限り、使い勝手が悪すぎだろと･･･そもそも複数ファイルな時点で･･･今更仮想CDにする利点も無いし･･･etc.etc.･･･

**名無しさん＠お腹いっぱい。** · 2010/02/02(火) 13:01:00

複数ファイルって何で駄目なんだ？
ape + cueだけど特に問題ないや

圧縮率を気にするのはこういうノートPCで持ち運びたいから
【オンキヨー】 BX407A4 【約370g】3
http://pc11.2ch.net/test/read.cgi/notepc/1263446133/

**名無しさん＠お腹いっぱい。** · 2010/02/02(火) 17:58:22

>>215
単ファイルの取り扱いの楽さに慣れたら、複数ファイルに戻れなくなる。
特に、ファイルシステム上からも音楽ファイルを扱う場合は。

圧縮率に対して自分で確かめてみたが、
apeよりもtakの方が優れていたり、変わらない場合も多いな。

CLANNAD Original SoundTrack DISK01(wav：748.839 KB)(主にBGM)
ape
-c5000：433.448 KB
-c4000：437.661 KB
-c3000：445.468 KB
-c2000：451.423 KB
tak
　-p4m：439.040 KB
　-p3　：443.675 KB
　-p2　：449.684 KB

続く･･･

**216** · 2010/02/02(火) 17:59:24

続き･･･

マクロスF　娘ドラ◎ドラ1(wav：441.540 KB)(主に人声)
ape
-c5000：206.013 KB（c4kより大きい）
-c4000：205.702 KB
-c3000：208.026 KB
-c2000：209.557 KB
tak
　-p4m：203.152 KB
　-p3　：204.348 KB
　-p2　：206.756 KB

圧縮順で並べると
上：a5<a4<t4m<t3<a3<t2<a2
下：t4m<t3<a4<a5<t2<a3<a2
の順となる。

**名無しさん＠お腹いっぱい。** · 2010/02/03(水) 13:08:59

apeスレでtakとの比較になったけどtakのメッセージとファイルサイズが合わなくて
実際には ape の方が上って結果になったけどちゃんとファイルサイズ見てる？

**名無しさん＠お腹いっぱい。** · 2010/02/03(水) 13:12:32

あ、takとtta間違えた・・・

takってそんなに圧縮率良いんだ
デコード不可はどんなモンだろう

**名無しさん＠お腹いっぱい。** · 2010/02/03(水) 13:17:33

でもこれ見る限りapeの方が圧縮率と圧縮速度が上だな
デコード速度はtakの勝ちだけど

http://www.synthetic-soul.co.uk/comparison/lossless/index.asp?Sort=EncodedSize&Desc=0

**名無しさん＠お腹いっぱい。** · 2010/02/03(水) 13:40:32

>>218
>apeスレでtakとの比較になったけどtakのメッセージとファイルサイズが合わなくて
が何を指すのか分からないですが、

MAC.exeとTAK.exeを使用してのエンコード
その後、名前を引数に付け替えた上で
エクスプローラー上の表示を詳細にして、サイズ毎にソートし、
表示されたファイルサイズをそのまま書いた。

という流れですが、問題有りますか？

**名無しさん＠お腹いっぱい。** · 2010/02/03(水) 13:55:05

>>220
この前、↓で
【EAC】可逆圧縮音楽のすすめ Part40【*+cue】
http://hideyoshi.2ch.net/test/read.cgi/download/1262103194/l50
「サイトによってflacのスピードが違うんじゃないか？」
との質問が出て、確かにどちらが正しいのか不明なので、
自分で比較してみるようにしていた。（Verも結構変わったし）

実際自分で試した方が間違い無いですしね。

**名無しさん＠お腹いっぱい。** · 2010/02/04(木) 03:11:38

>>220
>Last Updated: 21st December 2008

**名無しさん＠お腹いっぱい。** · 2010/02/04(木) 05:42:58

>>220
表の見方としては、
時間が短い=レートが高い
方が速度が上(早い)という見方になっていますね

**名無しさん＠お腹いっぱい。** · 2010/02/04(木) 05:50:21

&
オプションは

-c5000：Insane
-c4000：Extra High
-c3000：High
-c2000：Normal
-c1000：Fast

に対応しています

**名無しさん＠お腹いっぱい。** · 2010/02/06(土) 19:37:18

圧縮する際リカバリレコードを付けてくれるやつありますか？

**名無しさん＠お腹いっぱい。** · 2010/02/06(土) 22:05:00

>>226
その質問は、PNGやGIFにリカバリレコードついていますか？
と聞くようなもので、
基本的にrarやzip等の書庫ファイルとは性質が異なります。

**227補足** · 2010/02/06(土) 23:06:59

圧縮音声ファイルとは、音を鳴らす為の信号(PCM)を圧縮記述したファイル形式のことを指します。

ちなみに、
一般的にwavファイルとは、PCMを無圧縮記述したデータ(リニアPCM)を格納するファイル形式を指します。

簡単に言うと、
可逆圧縮音声ファイルは、wavやaac・mp3等と同じく音声ファイルの一形式であって、
wav等のファイル自体を圧縮している訳ではありません。

**名無しさん＠お腹いっぱい。** · 2010/02/06(土) 23:35:22

尚、rrではないですが、
takはエラー耐性の高いデータ構造をしています

**名無しさん＠お腹いっぱい。** · 2010/02/06(土) 23:40:39

>>227
別に違わないでしょ。
現時点では無いけど、そういう機能を持った可逆圧縮フォーマットが登場しても
全くおかしくない。圧縮した上で各ブロックをリードソロモン符号化して
冗長性を持たせるような感じで。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 00:05:03

>>230
まぁ、可能性を語ればいつかは出るかもしれないが、
圧縮データ形式自体にrr等持たせて複雑化及び肥大化させるより
保存時に外部でrr等を付けた方が効率的ということで、まず出ない気はする。

出るとしたら、メディアコンテナの方に機能を持たせる事かな。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 00:26:40

>>231
一度圧縮したものをrrのためだけにもう一度別のフォーマットでアーカイブし直すより
圧縮時に直接冗長性を持たせられる方が遥かに効率的でしょ。

rarやzipと音声の可逆圧縮を同列に扱わない理由が分からん。
どちらも可逆のブロック符号化器なのだから、同じものだよ。

**231補足** · 2010/02/07(日) 00:41:42

まぁ、画像にしても動画にしても音声にしても、
現状、rrによる破損による復帰より、バックアップによる破損への対処が一般的だからな。

データファイルそのものの音声ファイルと
他形式のデータを圧縮保存復帰を目的とした書庫とは考え方が違う

いわゆる、テキストデータ自体にリカバリレコードを付加させるのは必要か否か？
いつかは、rr付きのテキスト形式が出るかも？
という話になる。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 00:48:59

>>232
可逆圧縮音声ファイルという名前に惑わされているかもしれんが、

可逆なだけで、mp3やwavやaacと同じ音声ファイルですよ。
>>233にも書きましたが、最初からrr機能付きのgifやpngが出るかも？
と同じ話となります。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 01:04:24

>>234
???
音声ファイルや画像ファイル自体に直接rrを付加するのがおかしいという考えが
そもそも間違い。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 01:41:21

>>235
おかしいとまでは言わんが、効率の問題。

現在、ファイル自体の破損に対しては
データをrr等で修復するよりも、バックアップからの復帰が一般的な考え方。

書庫ファイルに関しては、それ自体がバックアップの性質を持つ為、
大きな破損に関しては無理だが、小さな破損に関しては修復の可能性を高める為rrを付けている場合もある。

簡単に言えば、現状のファイル自体に対する、修復とバックアップの考え方。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 02:12:04

言いたいことがさっぱり分からん。
音声可逆圧縮ファイルに対してrr(に相当するもの)を付加するのが何で非効率なの?
それ自体をバックアップ目的に使ってる人もいるのに。

**236付記** · 2010/02/07(日) 02:29:40

ファイル破損には、修復するよりバックアップからの復帰が一般的。（破損規模にしても復帰可能性にしても効果的）
↓
基本的に復帰がメインだからファイルフォーマット自体に修復は付けない(必要性が薄い)。
↓
修復ソフトは各自で。

となる。

その考え方が一般的だから、ファイル自体にはrr付加はされにくいだろうなと。
それが現状、一般的な大多数のファイル形式自体にrr等の修復機能が付けられていない理由。
rr付加はおかしいとまでは言わんが、効率（費用対効果）の問題。

ちなみに、>>237の答えは
可逆音声圧縮ファイルは、音声のバックアップファイルを目的として訳ではなく。
可逆的な、サイズが小さい音声ファイルを目的として作っているから。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 02:36:49

いや目的なんて人それぞれでしょ。
rrなんてメタデータとしてデータ自体に全く影響を与えずに付加できるんだから
そういうオプション機能を持ったフォーマットが登場してもおかしくないと思うけどね。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 02:54:45

目的なんて人それぞれですが
この場合、使用者の目的ではなく制作者の目的ですね。

ちなみに、
rr付加はおかしいとまでは言わないですが、>>238前半の理由で付加される可能性は低いだろうと。
現在の通常のほとんどのファイルフォーマット自体の修復機能（ソフトではなく）が付加されていない理由を考えれば
修復機能の可能性の率が見えると思います。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:08:42

???
あなたは製作者なの?

まあいずれにせよ
>基本的にrarやzip等の書庫ファイルとは性質が異なります。
というレスは完全に見当違い。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:18:36

製作者ではありませんが、
制作の目的が『可逆的な、サイズが小さい音声ファイルを目的』というのは見ていますが
『音楽ファイルのバックアップが目的』で制作というのは寡聞にして知りません。

見当違いの部分を指摘できずに、
書庫ファイルと音楽ファイルの性質が同じに見えてしまうのは
まぁ残念ですが、人それぞれですね。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:33:08

まぁいずれにせよ、
TAKやAPEが、WAVを格納したrarやzip等の書庫ファイルと同じに思っていたり、
PNGやＧＩＦが、BMPを格納したrarやzip等の書庫ファイルと同じに思っていたりするのでしょうね･･･理解して貰えず残念です。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:36:39

>>242
だからその性質が異なるってのが間違いなのだが?
229であなた自身が指摘しているように、TAK等はブロック毎にCRCを付加している。
これは『可逆的な、サイズが小さい音声ファイルを目的』には全く不要だが
信頼性のために行っている。この領域を単なるCRCではなく
誤り訂正符号のために利用すれば、(訂正能力の高さは別として)rrになるわけだ。

ちなみにFLAC等で音声ファイル以外を圧縮して復元することは普通に可能。
圧縮率が上がらないだけで。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:43:52

つ[スレ違い]

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:45:32

>>243
線形予測によって予測残差が小さくなるという情報源の性質を仮定して
特定の情報源に対するエントロピー符号化の効率を上げているだけで本質的には全く同じ。

複数ファイルをまとめて1つにする、というアーカイバとしての機能が無いという
点では違うけど、これはgzip等もそうだし。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:52:07

>>244
付加出来るだろうが、入れる意味が薄いから入らないだろうと言っています。
理由は>>238簡単に言えばバックアップファイルではなく音楽ファイルだから。

>flac等で～
単純にコンテナ形式のことであるから、aviやmp4をrarやzip等の書庫ファイルと同じに思っていたりするのと同様ですね。

というか、
PNGやＧＩＦが、rarやzip等の書庫ファイルと同じでしょうか？
若しくは
aviやmp4をrarやzip等の書庫ファイルと同じに思っていたりしているのでしょうか？

↑はどう思っていますか？

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:53:54

おっと、答えて貰っていますね、チト待って下さい

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 03:57:33

ちなみにFLACで音声以外のファイルを圧縮して復元する方法
圧縮
flac --force-raw-format --endian little --sign unsigned --channels 1 --bps 8 --sample-rate 44100 original_file -o compressed.flac
復元
flac -d --force-raw-format --endian little --sign unsigned compressed.flac -o decompressed_file

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:17:10

あなたの言いたい事をまとめると、
基本的に全ての変換ソフトは同じ情報を持つ事が出来ると言う点で書庫ファイルであり、
基本的に全てのコンテナ的形式は纏められると言う点で書庫ファイルである。

拡張していけば、0と1のデータの羅列という点で同じであるから、全てのデータは書庫ファイルである。
といえますな。

書庫ファイルとはまず何かを一致させてください。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:29:16

zipもbzip2もflac等も情報源のエントロピー符号化のための手法という点で同じ。
エントロピー符号化の効率を上げるための前処理として
zipはスライド辞書法を、
bzip2はblock sortingを、
flac等は線形予測を。
それぞれ利用している。

コンテナ云々という話は全く的外れ。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:36:37

>>251
その点で言えば圧縮する技法は違えど、可逆圧縮するという点では同じですね。
ですがそれは、同じ可逆圧縮ファイルというカテゴリになるだけですが？

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:38:03

要は、あなたはFLAC等をPCM音声を格納するためにしか使えない特別な形式だと
思ってるから、性質が違う、という的外れな指摘をしてしまっている。
実際はPCM音声で特に圧縮率が高くなる方式、というだけで、
zip等の一般の圧縮方式との本質的な違いはない。

>>226に対する答えは「今のところそういうソフトはない」で良かったのに
間違った知識に基づいた私見でものを言うからこうなる。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:45:09

基本的にtakファイル使いなのでコンテナ格納などが出来る事は知っていますが
用途が違うのでrrは搭載されないだろうと言っています

基本的に用途が違うファイルを、話が全然違うカテゴリーでくくって、
音楽ファイルもアーカイブファイルも、同じファイルと言うからこうなります。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:49:10

だから「コンテナ格納」とかいう話のレベルじゃなくって
音声以外のファイルも圧縮できるんだって。

あなたが圧縮ソフトの開発者ならともかく、新しい機能の実装の可能性について
(しかも間違った知識に基づいて) 断定的に言うのはおかしいでしょ。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:51:37

＆
ちなみに、zipやtak等は可逆圧縮と言う技法の一部で
圧縮形式は単に技法違いなのは十分理解もしています。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:52:54

takの技法でファイル等を圧縮出来る事は承知しています。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 04:59:55

ただ、同じ可逆圧縮ファイルというカテゴリというだけで、
用途は関係なく、同じ性質のものとしてrr等が
搭載する可能性が大というのもおかしな話だといっている。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 05:06:11

228や243の書き込みで、そうは理解していなかったことは明白。
可能性については、機能が実装されたところで(FLACでシークテーブル等の有無を選択できるように)
使いたくない人は使わなければいいだけなのだから
断定的に否定する理由はどこにもない。

まあこれ以上続けても押し問答にしかならないので止める。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 05:13:22

そのかきこみの、どこで理解していなかったのか不明。
最初から同じ事を言っている。

可能性については、他のファイル形式がなぜrrを内包してないのか考えれば分かると思うが･･･
断定的に否定する理由はどこにもないが、断定的に肯定する理由も無いがな。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 05:18:22

まぁ、確かにこれ以上続けても押し問答にしかならないな。
ゆっくり休んで下さい。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 07:41:45

なんかﾜﾛﾀ

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 13:56:41

レス番がすごい飛んでると思ったら・・・

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 16:44:11

ていうか、FLACとかはCD音源を「一時的に」HDDに記録しておくときに容量節約するためのフォーマットであり、
Zipなどの通常の書庫形式のように半永久保存を目的としていないから、rrなどは必要ない、ということでしょ？
圧縮データ形式としての本質云々は全く関係なく、どういった目的で造られたかでそこは決まるもの。
FLAC壊れてrrが必要になるのなんて、ほとんどの場合、P2Pでダウンロードしたとかで、取り込みなおせない人だけでしょ？
自分の演奏録音したとかで、どうしても消えたら困るのなら、rrじゃ不足で、複数メディアにバックアップだろうし。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 16:55:02

>>264
まるで「公式サイトにそう書いてありました！」みたいな自信に満ちた文章ですな。

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 17:07:46

P2Pの前にレンタルが浮かぶと思うけど…

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 17:15:53

なんだqtaacencの人か

**名無しさん＠お腹いっぱい。** · 2010/02/08(月) 19:40:03

MPCで使えるフォーマット無い？
DirectShow対応してるものしか無理かな

**名無しさん＠お腹いっぱい。** · 2010/02/08(月) 20:15:42

ffdshow入れれば

**名無しさん＠お腹いっぱい。** · 2010/02/10(水) 11:22:24

mp3HD テクノロジー
http://www.all4mp3.jp/learn/mp3hd.html

* ロスレス・オーディオ・コーデック　（CDと完全に同一なビットの複製）
* mp3との下位互換性
* 拡張子は　.mp3
* 曲のビットレートはジャンルによって　500~900　kbps (他のロスレス・コーデックと同様)
* 組込まれたmp3楽曲とmp3HD ファイルは、同じ　id3 メタ･データを共有
* 組込まれたmp3楽曲のエンコード・パラメーター（ビットレートなど）・補助データー・メタデーター等はコントロール可能

見向きもされねーなｗｗｗｗｗ

**名無しさん＠お腹いっぱい。** · 2010/02/10(水) 20:56:47

だって、遅いし、デカイし、ロスレスとしては汎用性ないし。
タグなんていう、多くのソフトが気軽に勝手にいじる不安定な部分に音声入れるって、そもそも無理がある。

DAPで採用するとしたらクリエイティブかサムソンかな、と思っていたが、案の定サムソンだったｗ

**名無しさん＠お腹いっぱい。** · 2010/02/12(金) 16:33:43

>>270
試しにエンコードしてみたけど一つのファイルになるんだね
WavPackのハイブリッドみたいに非可逆と差分で別ファイルだったら使うのに

**名無しさん＠お腹いっぱい。** · 2010/02/16(火) 01:13:08

ID3v2の"総タグサイズ"のサイズは28ビットらしいから
非可逆部が256MBを超えるようだと
ぶっ壊しちゃうタグエディタがいても文句は言えないな

**名無しさん＠お腹いっぱい。** · 2010/03/16(火) 21:38:46

>>227は「性質」と言っていたのに>>254で「用途」と言い換えており詭弁
そこに突っ込まなかった>>230は反省しる

**名無しさん＠お腹いっぱい。** · 2010/03/31(水) 11:24:48

>>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に確認しております。

ホントご丁寧にレスありがとうございました。

**名無しさん＠お腹いっぱい。** · 2010/04/02(金) 00:49:27

>>275
どういたしまして。

**名無しさん＠お腹いっぱい。** · 2010/05/02(日) 16:50:39

埋め込みcueのtakに対応しているプレイヤーって
foobar2000とwinampとQMPとあと何かあった？

**名無しさん＠お腹いっぱい。** · 2010/05/02(日) 22:36:31

>>277
Fittle

WinampとQMPって埋め込みcueに対応してたっけ？

**名無しさん＠お腹いっぱい。** · 2010/06/29(火) 14:44:47

>>270
エンコーダーがフロントエンドで他に対応したら使う

**名無しさん＠お腹いっぱい。** · 2010/06/30(水) 03:55:36

>>279
やめた方がいいと思うぞ
遅いし圧縮率低いし可逆対応の再生ソフト少ないし
一時期、MediaCoderのAudioEditionに含まれてたけど、今はどうかな
俺は普通にCLIでfb2kやdBpower使ったけど（勿論、常用じゃなくテストだけ）

**名無しさん＠お腹いっぱい。** · 2010/07/16(金) 07:08:00

>>10
このページ最新のPCでアップデートして欲しいよな

**名無しさん＠お腹いっぱい。** · 2010/09/12(日) 19:08:35

ほす

**名無しさん＠お腹いっぱい。** · 2010/09/12(日) 20:48:20

ここって、ちゃんとテンプレないんだな。
とりあえず、
>>3-6,9,10と、
>>12,13の鯖が古いので書き換えて、

関連スレ
Monkey's Audio　part4
http://hibari.2ch.net/test/read.cgi/software/1136974601/
音声可逆変換ソフト総合スレ
http://hibari.2ch.net/test/read.cgi/cdr/1219666212/

こんなところか。
次スレいつになるかわからんけど。