|
||
|
Amateur Member
 加入日期: Aug 2005
文章: 36
|
引用:
我google不到比較有嵌入跟沒嵌入cue的flac檔的討論耶 請問您還記得是哪個網站? 想參考一下 謝謝 |
||||||||
2011-09-16, 12:07 AM
#11
|
|
|
*停權中*
加入日期: Mar 2006
文章: 4,081
|
引用:
有差, 只要資料流和"時間"扯上關係, 就會有差 , stream是很難去進行即時校正的 這和檔案比對不一樣, 比對檔案沒有時間因素, 打個比方 , 如果一個時間帶的資料是001001001 有可能解成 001_001001 有可能解成 001001_001 資料上是一樣的, 但聲音是不同的 但是說這麼多, 實際上聽感真的相差甚小, 加上數位轉數位的過程的失真對於聽感來說更不明顯 可以當成是沒差, 而且有時候失真也不見得會變難聽, 不然真空管全都可以拿去燒了 此文章於 2011-09-18 08:35 PM 被 oScARSh 編輯. |
|||
|
2011-09-18, 08:33 PM
#12
|
|
|
Master Member
  
加入日期: Nov 2002 您的住址: 氣候越來越不友善的中部首善之區
文章: 1,773
|
引用:
不是這樣吧，編碼資料的解碼都有一定的規則 如果以你舉例的情況會變成對lossless編碼格式來說無意義的資料，解碼器它沒辦法解碼，變成爆音 我們要有一個觀念，聽起來有差是類比有差，不是數位有差 因為人耳不能直接聽數位，你聽出來有差不是證明數位資料流有差，況且數位也很難出錯，出錯也變成解碼錯誤，不是單純變不好聽 這也是我很難接受lossless codec的聽感比較的原因，這是他話 那數位沒差，類比會不會有差，這當然是肯定的，因為每台機器的DAC都有不同特性，機器的clock也會影響播放的品質，聲音訊號是時間訊號，時基準不準當然很要緊 好不好聽跟數位->類比好不好有關，跟解碼好不好無關，因為解碼只有對或不對，沒有好不好的問題 而且基本上不會有不對的情形，除非檔案本身就壞掉，單然還是有耗資源高或低的分別就是了 此文章於 2011-09-18 09:14 PM 被 feedback 編輯. |
|
|
2011-09-18, 09:13 PM
#13
|
|
|
*停權中*
加入日期: Mar 2006
文章: 4,081
|
請別誤會, 我也是支持decode在轉成pcm的過程中, 聽感無法分辨的
在這裡只是說可能有很小的差距, 我也強調差距很難用人耳去分辨, 除非這台解codec的處理器真的很差 , 差到光是D轉D就會有嚴重的jitter , 或是讀取裝置的資源嚴重被佔用, 加上很少的buffer讓即時decode造成些許的時基差, (例如某些很差的手機硬要播放高壓縮無損格式) 不然一般來說無損格式聽起來真的就和wave一樣 |
|
2011-09-19, 02:32 AM
#14
|
|
|
Master Member
加入日期: Nov 2002 您的住址: 氣候越來越不友善的中部首善之區
文章: 1,773
|
我大概知道你先前說的意思了
"打個比方 , 如果一個時間帶的資料是001001001 有可能解成 001_001001 有可能解成 001001_001" 這應該是你對jitter的解讀，如果我沒誤會的話 但其實jitter不是這個意思，jitter是指因為時鐘的準確性不一致，造成還原出來的訊號不在準確的時間位置上 你舉的例子有點像是本來「sample n的尾巴是001，sample n+1的開頭是001001」 變成「sample n尾巴是001001，sample n+1開頭是001」在處理 這就是我講的不應該要發生的情形，除非是codec有bug或是其他故障原因 解碼是一定每個人解結果都會一樣，就像我講的，除非有bug 但是不同機器有不同處理jitter的能力，還原出來的聲音訊號會有些微差距 |
|
2011-09-20, 11:47 PM
#15
|
|
|
Major Member
 
加入日期: May 2002 您的住址: 台北市
文章: 143
|
我剛試了一下，將手邊的 ape + cue 轉成 flac(內嵌cue)
然後再將 flac 轉成 1.wav + cue 接著將 ape + cue 轉成 2.wav + cue 上述都是用 foobar2000 轉的 1.wav & 2.wav 用 sha1 & md5 比，值都是一樣的 所以 flac(內嵌cue)應該跟原來的檔是一樣的 引用:
|
|
|
2011-09-21, 12:09 AM
#16
|
|
|
*停權中*
加入日期: Mar 2006
文章: 4,081
|
嗯...所以decode沒有時間序的關係,
它要如何在即時的條件 下去查檢每bit(資料)的編碼在每一個clock(時間)之下解出的東西都一樣 是否有什麼特別的設計呢 以影像解碼來說, 連續拉動seekerbar就會造成一些編碼上的錯誤和爆音 這代表音訊解碼的技術比較高囉 不知道有沒有程式可以連續串接100個encode和decode再放聲音出來, 這樣應該就能證明 decode (real-time) 到 音效輸出的過程完全沒有jitter ...不管怎麼樣, 這都是我聽不出來的  對了我的例子來說 就程式來看sample n 應該都是001001001 只不過它去對真實時間流來看, 可能第7和第8個bit之間decode完畢存在著0.0000000000001秒 可能另一個例子的第7個和第8個bit之間在decode處理花了0.0000000000002秒 (數字我打個比方) 我的想法是在CPU去decode這串資料時, 不能確保每一個bit之間的時間間距是否完全一致 而之後的stream到DAC再到揚聲器的過程可能都沒辦法進行時基的檢查... 這也只是我假設的猜想 當然如果decode是以sample為單位的話, 就可能是第n個和第n+1個sample之間的處理的時間差的問題, 同上 此文章於 2011-09-21 12:21 AM 被 oScARSh 編輯. |
|
2011-09-21, 12:14 AM
#17
|
|
|
Master Member
加入日期: Nov 2002 您的住址: 氣候越來越不友善的中部首善之區
文章: 1,773
|
如果是說lossless的解碼，單純就是數位對數位資料的重建而已
解得快、解得慢最後還是要排排站進DAC，DAC的jitter不受前面解碼器的影響 lossless在硬碟上就是等效於wav，這是我的想法 PCM的話，他結構我不懂，我只曉得規格而已 DAC他怎麼把取樣資料重建回波形實在是超出我知識範圍了 我是這麼想的，還原sample資料不用去管他的精確時間，比如說sample n的時間軸位置tn到底是多少，幾分幾秒幾毫秒又幾微秒?不管他 今天1秒鐘的PCM有44100個sample，我只要把這44100個sample都還原好了他的振幅 然後搭配好超精準的clock，確保一秒中的每一個1/44100等分間隔都一致，那出來的波形就很整齊了 |
|
2011-09-23, 12:10 AM
#18
|
|
|
*停權中*
加入日期: Mar 2006
文章: 4,081
|
感謝分享心得, 加上你的想法
我本來想全wave的計劃看來可以先放著了 |
|
2011-09-23, 09:36 AM
#19
|
|
|
Amateur Member
加入日期: Aug 2005
文章: 36
|
感謝您
我可以放心轉檔了 引用:
|
|
|
2011-10-01, 03:40 PM
#20
|
|
