#BACK TO MINE FLAC ZIP#

192/24 is partly about the hardware and distortion of higher formats, but he spends a lot more time in there talking about what we don't hear. The argument Montey is making for 44.1/16 vs. At lower bitrates, it's about removing the things you hear less. It's literally about removing the things you don't hear. The major 'hack' in lossy formats is psychoacoustics. Maybe we're due for a new lossless audio encoding?) Possibly made sense in the late 90s, when a PC's RAM wasn't much larger than five minutes of uncompressed audio. Seemingly they were all designed under the presumption of the constraint that the encode step must be able to be done in hardware / with fixed-sized memory buffers rather than allowing that you can load the whole PCM audio file into memory and do things like FFT to it. (ETA: the other later lossless audio formats that I'm personally aware of - ALAC, Monkey's Audio, and WavPack - all seem to use linear prediction. wavelet LUTs as your primitive (plus maybe a larger block size)?Īre there other, more advanced lossless encodings that do this? And if so, why didn't they catch on compared to FLAC?įor that matter, is there a lossless format that just embeds a regular lossy encoding of the audio as the approximation, and then computes+stores the residual relative to that? (I'm guessing that this wouldn't work well for some reason, but I'm not sure what that reason would be.) Couldn't you get a much better approximation (⇒ more compressible residual) in about the same amount of storage space + CPU decoding effort, using a formula based on e.g. Think in terms of having a one-second silence recorded as 'Zero, then 44099 more of 'em' rather than 'zero zero zero zero zero.' and so on 44100 times.Ĭurious to me why only such a simple representation (polynomial) is used for the approximation.

#BACK TO MINE FLAC ZIP#

A low bitrate MP3 is like trying to redraw the original waveform from a vague description with a paint roller, a high bitrate MP3 is like trying to draw it with a mapping pen from a really detailed description.įLAC audio is lossless because it takes the precise values of the audio, and uses a technique similar to zip files to find similar-looking blocks of data. The higher the bitrate, the better the description, and the more detailed the reproduction. MP3 audio is lossy in that rather than storing the exact values of a waveform, it stores a description of how short segments of the waveform change. The only problem is, this takes up a lot of space, roughly 10MB per minute for stereo audio. When you play it back you get exactly the same signal back out. When you listen to music there's a lot of 'fine detail' that you can't really hear that gets buried by louder sounds.ĬD audio is perfectly lossless - it encodes the signal that you put in by measuring a voltage 44100 times per second and recording that exactly.

You really need a table of rules for doing the checksum otherwise it's a wasted effort. If you want to hack in checksums for track bitstreams both MOV/MP4 and Matroska can accept arbitrary tags for tracks so you can just write a checksum to a track header tag if you really want to. Are we checksumming the track bitstream and important track headers? A video needing to render in a particular color space will be materially affected if it's bitstream is preserved but color space tags are dropped. Media tracks can also have header tags that indicate stuff like display color space, displayed size, or even track level metadata. But when it comes to checksumming the track do we checksum all the samples in the track or only the samples that will play? If a file if flattened and a track has all the samples out of the playable region discarded do we now have to recalculate the checksum? Are we just checksumming the compressed bitstream? Where in the handling of the bitstream are we doing the checksum? In MOV/MP4 a media track can have arbitrary start and end times. It's less straightforward with a lossy compressed codec. It's no different from a checksum in a compressed archive. You want to know what was encoded losslessly matches the input. In the case of FLAC the situation is straight forward, you've got uncompressed audio and a codec that's performing lossless compression. So each codec and combination of track/codec needs its own special case on how and when a checksum is performed. Checksumming in media container formats is tricky because different media formats have different features.