|
|
Rip losslessly to flac with abcde
No, that is not true. Giving input which does not meet the specification is an invalid test. These codecs expect audio. If you throw at it non-audio you have an invalid test. If you have a system that will do arithmetic on dollars and cents and you give a test suite including data with 10ths of cents you have an unreasonable test.
Rip losslessly to flac with abcde
It is true. These codecs expect audio in the sense that the input must be a valid audio format supported by the codec but it does not matter what type of signal was encoded in that audio format. It could be music, a square wave, noise, or a list of winning lottery numbers -- it makes no difference to the encoder.
Rip losslessly to flac with abcde
Not really true -- a true square wave has infinite frequencies (or at least higher than the sampling rate and your range of hearing), which any encoder (even "lossless" WAV) will alias to lower frequencies that you "can" hear. So if one encoder suppresses these alias frequencies better it doesn't make it more "lossless" -- you've simply passed data to the encoder that the writes didn't expect -- non-audio data.
Rip losslessly to flac with abcde
Yes, it really is true. I'm talking about the codec being lossless. If the audio samples coming out match the audio samples that went in, it's lossless. You're talking about the sampling process being lossy, which of course is true, but it's a totally different issue.
Rip losslessly to flac with abcde
The thing the codec is trying to be smart about is to work with audio that really will come along. If the inventors of a codec realize through analysis of real audio that certain frequencies never come up in real life, then develop a codec that takes advantage of that truth of nature they may have an insight that allows a significant advance in technology. So if it is lossless with real audio but loses certain frequency components in fantasy signals I would still call it lossless.
Rip losslessly to flac with abcde
"Lossless compression" means no information is thrown away.
MP3 and FLAC are analogous to JPEG and GIF, or ZIP. JPEG and MP3 throw away information that is considered unimportant, or below our threshold of detection. FLAC, GIF and ZIP should take some binary stream and compress it in a way that that stream can be recovered PERFECTLY. Arguing about square waves misses the point -- FLAC can encode any valid PCM stream and reproduce it bit for bit on decompression. The sampling process that makes a true square wave impossible is not the issue here. D.
Rip losslessly to flac with abcde
No, that is not true. Giving input which does not meet the specification is an invalid test. These codecs expect audio. If you throw at it non-audio you have an invalid test. If you have a system that will do arithmetic on dollars and cents and you give a test suite including data with 10ths of cents you have an unreasonable test.
Sorry, you're flat-out wrong. FLAC is designed to compress any PCM stream so that it can be decompressed without loss. It is designed to be very efficient for music, but it should never lose information for any PCM stream including white noise, square waves, etc. If somebody was complaining that FLAC didn't achieve a high compression ratio on white noise, then your criticism would be justified. Indeed, it's likely that FLAC "compression" would make a white noise file larger. Even the 180 out of phase test is a mistake if you do not adjust for different latencies. And if the latencies vary over time it should also not matter. The out-of-phase test would be trivial to get right, but why bother? The only thing that matters is the binary difference test. Actually, I guess it might be a useful way to find out if the errors were spread out over the entire file or just in one chunk somewhere. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.07 seconds |
|