Hacker News Reader

Comment by mustache_kimono | Hacker News Reader

FLAC makes lots of smart decisions. One constraint on lossless audio should, of course, be that it's actually lossless (which the test suite confirms), but also that it makes it easy for the user to confirm the audio streams are the same as the decoded WAV file (`flac -t`) by storing a checksum of the stream.

I have often wondered why other media formats don't do a similar thing, especially since changing a media file's tags (which can change the checksum of a file) or name (which makes external verification from txt file difficult) is quite common. I even wrote a utility[0] that uses ffmpeg to hash all ffmpeg compatible bitstreams, and store their hashes in a xattr (yes, with lots of other options to test and compare, etc.), but all media formats should just be as clever (and care as much) to do this natively, like FLAC.

I mean -- why not?

[0]: https://github.com/kimono-koans/dano

View on HN

This was how I discovered my problem when I had bad non-ECC RAM in a machine with ZFS.

Not often do I find a comment that brings up very similar experience. Had intermittent data corruption because memory bit error on very upper range that almost always was unused and went unnotced a long time. ZFS backend PC was actually ok, it was main PC that used the share but point remains. After that no more non-ECC memory ever on any computer for me (ok except some laptops).

I'm only going to add a related anecdote that wasn't a failing of ECC vs non-ECC but rather of BIOS behavior.

Background: Lenovo Thinkpad T520 laptop, random crashes and data corruption.

Diagnosis: Eventually let memtestx86+ run a bunch of times for like a week and it wasn't showing any errors. Finally about to give up I pressed some key on the keyboard and it blew errors immediately all over the screen. This suggested EC or maybe some BIOS-controlled keyboard driver was writing to memory it shouldn't have been.

Fix: I am a Linux user, the kernel has an option to reserve low memory for poorly behaving BIOS that likes to write where it shouldn't. CONFIG_X86_RESERVE_LOW should be set to at least 64kb and increased up to 640kb if this issues continue to happen. There are some other options to scan for this misbehavior but I honestly don't know how Linux currently handles it: https://lkml.org/lkml/2013/11/11/683

Linux actually switched recently to leaving the whole bottom 1MB to the BIOS: https://lore.kernel.org/lkml/YLx%2FiA8xeRzwhXJn@zn.tnic/T/#u

Apparently Windows now does it too because too many BIOSes are buggy: https://bugzilla.kernel.org/show_bug.cgi?id=16661#c2

Yep, that's a smart feature. It had actually uncovered bugs in FFmpeg's FLAC encoder multiple times. [1][2] (why they didn't just use the reference implementation is beyond me...)

But I have one nitpick with FLAC in this regard: they chose MD5 as the checksum instead of something sensible like CRC32/CRC64... It makes no sense, because we're not doing cryptography here - we're doing an integrity check. Moreover it makes a parallelized FLAC encoder somewhat problematic to implement, as there's always going to be a serial bottleneck at the end for computing the MD5 hash. CRC on the other hand could easily be parallelized. But I'm afraid we'll have to live with this shortcoming forever now ¯\_(ツ)_/¯

[1] https://trac.ffmpeg.org/ticket/4628

[2] https://trac.ffmpeg.org/ticket/4421

Agreed. FYI, ffmpeg's hash testing format [0], and therefore my utility dano, allows the use of CRC32, etc., though.

> But I'm afraid we'll have to live with this shortcoming forever now ¯\_(ツ)_/¯

I don't believe there is a fundamental reason why a later version of FLAC couldn't/wouldn't allow different algos as I think the raw decoded bitstream is checksum-ed and is just stored as a FLAC tag[1]. So they could just version that tag.

[0]: http://underpop.online.fr/f/ffmpeg/help/hash.htm.gz [1]: Language corrected. See comment.

>I think the file is decoded and then checksum-ed and the checksum is just stored as a FLAC tag.

Sure, it's just metadata. It's just about backwards compatibility.

By the way, the checksum is calculated on the raw data fed into the encoder. It doesn't make sense to decode the data you've just encoded.

> It doesn't make sense to decode the data you've just encoded.

Unless you're also writing to disk and reading it back before decoding - I'm not sure which tool you're referring to.

Are there any good ways to tell if audio has been lossy compressed but then re-encoded in a lossless format, or deceptively high lossy bitrate?

You can view it with a spectrogram, audio which has been lossily encoded will have a telltale cutoff in the high frequencies. The lossier the encoding, the lower the frequency ceiling will be.

Another thing to look for is deleted or very flat energy between harmonics. Reducing bit rate in inter harmonic regions is most of what's meant by 'psychoacoustics.'

I imagine low pass filtering depends a bit on which compression you're using.

None of these tricks will work for detecting GAN compressed audio, though.

There are a number of python utilities (via scipy, etc.) that claim to do this by checking for the frequency cutoff. See FLAD and fakeflac.

I couldn't find FLAD but fakeflac doesn't seem to work, even given actual mp3s it claims they are fine :(.

I'm guessing sometimes frequency cutoff is due to using less than ideal microphones, although not the extreme cutoffs (I'm fairly sure it would be gradual in that case). It also seems there is often a fair amount of noise around 20kHz that I'm guessing is from recording equipment, sometimes on tracks that otherwise look suspiciously like they are from lossy audio. Additionally, in some cases there could potentially be high frequency cutoffs in processing while otherwise being lossless, particularly stuff like electronic music where there can be a lot of processing in general. So I'm not sure if it is necessarily all that easy to tell in general, although there are certainly some from Bandcamp that seem highly likely to be conversions from lossy formats :(.

You can read the spectrogram.

https://interviewfor.red has lots of info about that exact thing, because in some uh… very peculiar communities, sharing a lossy file passed as a lossless file is a serious offense.

I love how that site has become the de facto main introduction resource to audio compression - makes sense though!

It’s the best layman resource out there IMO, also the fact that you might get a chance to get into RED… nothing wrong in that :-)

I see you’re a man of culture ( ͡° ͜ʖ ͡°)

Yup, it's incredibly clear in the spectogram.

You're basically looking for two things: first, an abrupt stop to frequencies above a certain point -- compression uses applies a low-pass filter to eliminate them.

Second, a bunch of rectangular-ish boxes where signal is missing. The spectrogram will look like swiss cheese in a way -- this is where the compression algorithm decides audio information can be deleted because it's "masked" by e.g. louder surrounding sounds.

(Generally speaking, the more aggressive the compression, the lower the frequency ceiling, and the more/bigger swiss cheese holes.)

On the other hand, if you run e.g. AAC compression at a very high bitrate and explicitly force no lowpass filter at all (which virtually nobody does in practice, but you can do from a command-line tool)... you won't be able to see any qualitative difference. Because you won't be able to hear any qualitative difference either. :)

Audiochecker (https://archive.org/details/Audiochecker.v2.0.Beta.Build.457) is amazingly good at detecting WAV/FLAC that is really just a re-encoded from MPEG. It's specific to MPEG though, so it wouldn't be able to detect e.g. Vorbis converted to FLAC.

Looks like that uses aucdtect:

http://tausoft.org/wiki/aucdtect

I wonder if there is any open source implementation of the algorithm it uses.

http://tausoft.org/wiki/True_Audio_Checker_Algorithm

There is https://losslessaudiochecker.com/ - not sure how well it works.

Checksumming in media container formats is tricky because different media formats have different features. So each codec and combination of track/codec needs its own special case on how and when a checksum is performed.

In the case of FLAC the situation is straight forward, you've got uncompressed audio and a codec that's performing lossless compression. You want to know what was encoded losslessly matches the input. It's no different from a checksum in a compressed archive.

It's less straightforward with a lossy compressed codec. 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 makes doing in/out cuts super fast. 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?

Media tracks can also have header tags that indicate stuff like display color space, displayed size, or even track level metadata. 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.

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. You really need a table of rules for doing the checksum otherwise it's a wasted effort.

PNG - another very well engineered format - also stores a checksum of the image data as well as checksums of every metadata block.

But I guess most people and thus file formats don't care. If your file's corrupted and you don't notice it doesn't matter. And if you do notice you don't need a checksum to tell you. I don't necessarily agree (knowing where the corruption occurred is useful), but I can see the reasoning.

Actually I have a related question about CDs: do any CD players indicate when the (Reed-Solomon I think) forward error correction actually corrects any errors? This could give an indication of the quality of the media. It could be total corrected error count, or corrected error count per minute.. something like that.

Second, do any give an indication of when the error correction fails: I think CD players just fill the missing data with the last sample value (certainly this was the case for first gen CD players)- but this FLAC encoding gives a better procedure: replace the missing samples from those of a predictive model. But either way, it would be nice to know when the playback is not perfect.

As to your second question:

> Some ROM drives are capable of reporting C2 error information along with the audio data and some ripping software can use this information to determine whether the retrieved audio data is valid or not. A standardised mechanism for ROM drives to report C2 error information is documented in the Multi-Media Command (MMC) standard

https://docs.linn.co.uk/wiki/index.php/CD_Ripping_Terminolog...

I've never personally seen that on a dedicated player (appliance nor software), I assume because they are more interested in keeping the music playing.

Exact Audio Copy shows it but will spend minutes re-reading the same frames: https://i.imgur.com/ZGozdhz.png (screenshot mine, unfortunately)

If you’re somewhat lucky, you’ll be able to repair it with CueTools via CTDB.

My experience backing up up audio cds with Exact Audio Copy tells me that CD players have limited error correction facilities and using EAC is the only way to know! (read retail CD brand new get same as reference checksum, read same CD ten years later, mismatch errors popup on a few tracks), the FAQ on EAC gives some details on CD player capabilities - standalone audio CD players use oversampling and more but most don't tell you when it kicks in - there's typically only one small LCD/LED line of display. https://www.exactaudiocopy.de/en/index.php/support/faq/

Well this gives me an idea for an interesting FPGA project. The early CD players, like Sony D-5 (I just looked at its service manual), have accessible recovered clock and data signals (they are buried in a chip for newer devices). It would not be too hard to make the EFM decoder, de-interleaver, and error corrector in an FPGA so that I can have these features.

How much would audiophiles pay to have a quality indicator on their CD player? Hmm...

Edit: Sony's CXD2500BQ shows error correction information on the pins- no FPGA needed.

CXD2500BQ is used in Onkyo's DX-7310

This company claims to have a product for this (but no pictures..), follow the links for their "CD Errormonitor":

https://www.wpnsystems.com/

> there's typically only one small LCD/LED line of display.

Still-- why not just output Quake on that line and subtract the error correction from the starting 100% health?

Many years ago (> 25) a friend's cd player showed this information, I think it was a denon.

cdparanoia [1], also from Xiph, reports (and attempts to correct) such errors.

[1] https://www.xiph.org/paranoia/

I have a fairly large collection of DJ music and this tool sounds extremely helpful for management. Thank you!

You probably can store hashes in MKV, not sure if there is a dedicated field for that.

I want something like that for JPG, with parity.

What are the reasons why not? What are the obstacles/drawbacks to the FLAC approach?

I have no domain knowledge here, just curious

For the most part, no one cares to do so is why.

Hell, 99% of all computers are still running on non-checksummed filesystems, if not 99.99%.

For the most part, only a tiny minority of people are even aware of bit rot, let alone have anything they simultaneously care enough about to protect against, and have enough ownership of it to attempt to try.

ELI5: What is preserved when it is "LOSSLESS" - what portion of a wave, or quality or (i dont know what term to ask) is dropped when "LOSS" occurs?

usually frequencies too high to be heard.

The lossless encoded signal is bandwidth limited already - lossy compression has to exploit more sophisticated perceptual phenomena such as masking.

Cutting down the bandwidth (lowering the sample rate) wont sound as good as an actual lossy codec - otherwise we could just resample.

#Subscribe

From my understanding (I took two relevant undergrad courses, definitely not an expert) lossy compression can involve either losing certain frequencies (like those above/below human hearing), or losing the accuracy of the reproduction (like a certain frequency component of the sound could be the smallest bit louder/quieter or higher/lower than it was originally).

The key point is masking: if a sound at a given frequency is loud enough, you are less likely to perceive weaker sounds at other frequencies. So there is little point in wasting bits on those frequencies during the time intervals where they are being swamped.

The exact frequency/amplitude relationships where masking effects come into play were studied by the telecoms early on (meaning in the 1950s-1960s era), and are still a key part of most lossy encoding models these days.

See https://en.wikipedia.org/wiki/Critical_band and https://en.wikipedia.org/wiki/Psychoacoustics as an introduction to the principles.

Lossy codecs try to find an approximate signal that sounds as close as possible, but is easier to compress. They drop parts of the signal entirely, or reduce their resolution, based on models of human hearing to identify the parts that are least likely to be noticeable if they are missing. E.g. not all frequencies can be heard equally well, so quality is dropped on the ones that are heard less clearly anyways. And loud signals on one frequency can make signals on another frequency or following quickly after harder to perceive.

Most such audio codecs are based to some degree on variants of fourier transforms, so this modification is done by dropping or reducing resolution of parts of the output.

If you feed an .EXE file into the FLAC encoder, you'll get a file with white noise, but you can always restore the original .EXE by decoding the FLAC.

You cannot do the same with MP3, AAC, OGG, Opus or any other lossy codec.

When you listen to music there's a lot of "fine detail" that you can't really hear that gets buried by louder sounds.

CD audio is perfectly lossless - it encodes the signal that you put in by measuring a voltage 44100 times per second and recording that exactly. When you play it back you get exactly the same signal back out. The only problem is, this takes up a lot of space, roughly 10MB per minute for stereo audio.

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 higher the bitrate, the better the description, and the more detailed the reproduction. 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.

FLAC 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. 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.

> CD audio is perfectly lossless - it encodes the signal that you put in by measuring a voltage 44100 times per second and recording that exactly. When you play it back you get exactly the same signal back out.

Not at all! CD audio amplitude is quantized to 16 bits, and temporally sampled at 44100 Hz as you say. Certainly very high quality, but there's absolutely a loss (that nobody can really hear).

In terms of media formats lossless in practice means "relative to the input device".

Otherwise image formats could not be lossless for the same reasons (at the very least very few of them store the polarity of the light)

Holography stores phase, I guess.

> that nobody can really hear

I know that when I was about 10yo, I could hear a tiny suggestion of something audible when I tested my hearing at around 23-24kHz. I guess that if you had some really loud content around these frequencies and had equipment that could reproduce it perfectly, it would be not impossible for it to influence my listening experience those many years ago :)

I used to be able to locate the computer section of WH Smiths or John Menzies in the 1980s and go and play on the ZX Spectrums and Commodore 64s (and other oddities - the one in Arbroath had a couple of Memotech MTX512s!) by hearing the 15kHz scan line whistle from the CRT tellies they used for displays.

Although there's also a difference between being able to hear a single tone, and being able to reliably perceive a difference in some more complex bit of noise.

Testing with https://www.audiocheck.net/blindtests_frequency.php, my hearing limit in the white noise case for example is at least 1 to 2 kHz lower than my hearing limit for a single frequency sinus tone.

Oh absolutely, hence the stressed out words in cursive. It isn't going to make any meaningful difference even for a 10yo with perfect hearing - for listening, 44100Hz sample rate is more than enough, and 48000Hz provides large enough headroom to already make any semi-reasonable "audiophile" sleep calm.

That's not what lossless means here (or anywhere).

What would you say that lossless means, then?

It isn't me making these definitions. It means that a digital signal is encoded in a way that does not lose information from its original encoding.

https://en.wikipedia.org/wiki/Lossless_compression

https://en.wikipedia.org/wiki/Audio_Lossless_Coding

https://en.wikipedia.org/wiki/Category:Lossless_compression_...

This is very common terminology.

Lossless to all practical purposes, then. With 16 bits of amplitude quantisation the smallest bit is below the noise floor of all but the quietest possible amplification, and while 44.1kHz isn't a lot it still places the corner frequency of your antialiasing filter comfortably above human hearing.

It's got way more audio bandwidth than most of the analogue masters that everyone raves about.

No, there's nothing magically audible happening with phase shifts near the steep cutoff of the antialiasing filter that isn't happening with the gentle rolloff of tape, either. Not that you could hear anyway, and even though my hearing is better than most 48-year-old industrial music enthusiasts, not that I could hear either.

For cats, even your very best equipment with perfect reproduction sounds like AM radio because their hearing tops out at 80kHz.

Absolutely

Im in love with you.

Thank you

> What is preserved when it is "LOSSLESS"

Just like any general purpose compression: everything - flac could be used just like zip/zlib/gzip as a general purpose compressor it just wouldn’t compress as well on most data that isn’t audio.

> dropped when "LOSS" occurs?

Lossy compression generally employs some type of perceptual coding where data is reorganized such that the signal data is sorted or localized according to its perceptual importance. This does partly involve removing or reducing the density of signal in the higher frequencies but it also exploits things such as masking both in time - inability to perceive signals occurring close in time of similar frequency. And frequency masking - our inability to hear quieter signals that are close in frequency to a louder one.

What would the point be of storing a checksum of the original data if the compression technique is known to be lossy?

You could use a CRC to verify metadata contents.

But IMO these are the properties of a good container file / stream format. FLAC might define its own but IMO most codecs could work well with a generic container.

It doesn't? However, it may be significant to store a checksum of the lossy bitstream?

Reply on news.ycombinator.com