作者: 笨蛋葉 時間: 2015-1-7 01:02 標題: APE>WAV
因為部機唔支援APE,想問APE轉WAV 對音質係咪無影響
作者: powershing 時間: 2015-1-7 07:15
因為部機唔支援APE,想問APE轉WAV 對音質係咪無影響
笨蛋葉 發表於 2015-1-7 01:02
照計就無咩影響，
不話D大師一定聽到分別
作者: ip4368 時間: 2015-1-7 10:59
照計就無咩影響，
不話D大師一定聽到分別
powershing 發表於 2015-1-7 07:15
其實根本解釋唔到. 有人試過wav->ape->wav, 對比前後wav檔嘅md5等, 係完全一樣.
如果用player播ape就話可能real time trans-code令到又分別, 但轉左檔先播, 話又分別根本就係心理問題, 如果blind AB test應該唔會分到
作者: 笨蛋葉 時間: 2015-1-7 17:38
其實根本解釋唔到. 有人試過wav->ape->wav, 對比前後wav檔嘅md5等, 係完全一樣.
如果用player播ape就話可 ...
ip4368 發表於 2015-1-7 10:59
如果FLAC轉番做WAV呢?
我睇人話APE<>FLAC<>WAV 之間轉換係無唔同
作者: ip4368 時間: 2015-1-7 18:06
如果FLAC轉番做WAV呢?
我睇人話APEFLACWAV 之間轉換係無唔同
笨蛋葉 發表於 2015-1-7 17:38
無錯, FLAC轉返WAV都係無唔同的. 不過的確聽過有人做blind test在某些player上, 播FLAC/APE係同WAV有分別, 就應該係real time嘅問題. 基本上所有lossless compression都可以互換而無loss, 除左上述3種, 仲有一種Apple device用, 叫ALAC.
作者: ikki55 時間: 2015-1-7 22:07
APE本身巳經唔多掂, 係大陸因政治決定先興起, 全世界都唔多人玩, 如果你係玩老番, 我勸你唔好攪咁多嘢
作者: 笨蛋葉 時間: 2015-1-7 23:10
APE本身巳經唔多掂, 係大陸因政治決定先興起, 全世界都唔多人玩, 如果你係玩老番, 我勸你唔好攪咁多嘢 ...
ikki55 發表於 2015-1-7 22:07
想理解下APE本生，因為的確細好多
作者: 笨蛋葉 時間: 2015-1-7 23:11
無錯, FLAC轉返WAV都係無唔同的. 不過的確聽過有人做blind test在某些player上, 播FLAC/APE係同WAV有分別 ...
ip4368 發表於 2015-1-7 18:06
ALAC 我都知
多謝你熱心解答我問題
作者: snp386 時間: 2015-1-8 02:05
每轉一次數字上係有分別，但係你唔係轉十次八次基本上正常人係聽唔出，係高頻先會分得到
作者: 松鼠仔 時間: 2015-1-8 10:10
如果單一個wav分返開，又有無問題?
作者: 伏喱哩 時間: 2015-1-8 10:14
照計就無咩影響，
不話D大師一定聽到分別
powershing 發表於 2015-1-7 07:15
1/3*3
會唔會=翻1丫
作者: 高登阿伯 時間: 2015-1-8 16:19
回覆 3# ip4368
我自己有個唔多科學嘅解釋，ape同wav係解碼時候係有分别，ape要解先壓縮轉翻PCM至可以解碼，wav就唔洗，所以DAC嘅工作量、latency等等唔同晒，所以聲音有分別但對比轉換前後wav檔嘅md5完全一樣。
純粹靠估，有錯勿拍。
作者: darkfrank 時間: 2015-1-8 19:11
本帖最後由 darkfrank 於 2015-1-8 19:13 編輯
事實上md5、crc相同的同一文件但聽感不一樣，台灣p900派好早就提出過因為讀入內存後並非連續位址而造成
到最近極聽作者TS都研究得出類似結論而係播放器用了以下技術:
"JEP是大页内存对齐的，我通过两次进程调用截断了内存与物理文件的关联。"
Q:大页内存对齐是什么原理？
A:大页内存即是large size Page，内存分配粒度，系统默认是4kb。
Q:已读入内存的数据还需整理否？
A:要，按页对齐"
Q:那ssd应该不需要数据整理了？
A:理论如此，实际还是有一点影响的，毕竟没有对齐的数据，读起来开销要大一些
到呢幾日剛好有人介紹日本BugHead Emperor作者Mr. Yokota的一款文件整理軟件Rewrite Data也是利用了內存重排技術
Fidelizer 作者對其原理的猜測:
1. Rewrite Data copy file to memory
2. Rewrite Data optimizes data in memory buffer using ReWriteMemory using optimized data block process such as non-temporal mov, no CPU cache memory buffer, MMX register, bit holding voltage rise, etc.
3. Rewrite Data save optimized data block from memory buffer back to storage again with ReWriteMemory optimization. This process is done on strreaming buffer like optimizing and writing back to storage every 8192 bytes.
So rewritten data is optimized solely for that machine to be fully effective. I'm not sure how effective it'd be on different OS and machine though. I'll try to ask Mr. Yokota out tomorrow.
以下是jplay forum的討論串
http://jplay.eu/forum/computer-a ... t-rewrite-data-1.0/