|
|
Rip losslessly to flac with abcde
We used a couple of different methods to test the codecs with some specially crafted audio samples.
Rip losslessly to flac with abcde
Then I think your tests WERE flawed.
Rip losslessly to flac with abcde
It doesn't matter if the source file is music or noise. Lossless should be lossless. If there are any errors with any type of input, the audio codec isn't truly lossless.
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.
Problems with your test methods ...
In reading your test methods, I have to say it seems as if each one is significantly flawed in some way (although you may have omitted details for brevity's sake). Warning -- this post is overly long! I apologize, but I thought that Gerk might want some constructive criticism.
Problems with your test methods ...
Some good points here. Having sounds compared by using phasing is kinda of pointless. In general when generating any kind of extra processing it's hard to keep track of possible added variabilities along the way.
Be more careful with presentation
It appears that your methodology is sound, but you should be more careful about how you present these results. It's quite likely you're revealing bugs with one implementation of the FLAC algorithm, not fundamental problems in the design of FLAC. Unless you show your test files to the FLAC team and they say "yes, this is a design flaw and no, we aren't going to fix it" then claiming that "FLAC is not a lossless format" is inaccurate, misleading, and defamatory, and you're opening yourself up to a boatload of justified flameage.
Be more careful with presentation
Because saying "This codec loses something, therefore is not lossless" is entirely inflammatory and unfair.
Be more careful with presentation
Because saying "This codec loses something, therefore is not lossless" is entirely inflammatory and unfair.
No, because saying "FLAC is not a lossless codec" is different from saying "one particular implementation of FLAC has a bug that can cause loss." Claiming that the FLAC algorithm is not lossless is an accusation that its authors are intentionally misleading people by saying otherwise. I would say that without some serious evidence, yes, such a claim is inflammatory and unfair. It's FUD, plain and simple, because it leads people to the incorrect conclusion. Just like saying "The phone company isn't giving you a free cell phone" when part of your bill says "Free phone fee: $270". No, not really. It's more like claiming "The phone company is lying and isn't giving anybody a free cell phone" when they actually just accidentally billed you for it but were completely willing to correct their mistake. The difference is what you're saying about the intent of the other party.
Be more careful with presentation
And you're certainly not assigning malicious intent to his statements, no sir.
Be more careful with presentation
And you're certainly not assigning malicious intent to his statements, no sir.
Actually, if you read my post you might notice I said nothing about his intent, only the nature of his statements. I can understand the mistake -- it's a subtle distinction. |
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.14 seconds |
|