[HN Gopher] FLAC - Format overview
___________________________________________________________________
FLAC - Format overview
Author : jsbg
Score : 191 points
Date : 2022-09-05 18:53 UTC (4 hours ago)
(HTM) web link (xiph.org)
(TXT) w3m dump (xiph.org)
| mustache_kimono wrote:
| 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
| Lammy wrote:
| This was how I discovered my problem when I had bad non-ECC RAM
| in a machine with ZFS.
| hnuser123456 wrote:
| 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?
| dmitri_ignat wrote:
| 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.
| sdenton4 wrote:
| 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.
| mustache_kimono wrote:
| 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.
| TonyTrapp wrote:
| Audiochecker (https://archive.org/details/Audiochecker.v2.0.B
| eta.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.
| gsora wrote:
| 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.
| aaaaaaaaaaab wrote:
| I see you're a man of culture ( deg [?]? deg)
| piperswe wrote:
| I love how that site has become the de facto main
| introduction resource to audio compression - makes sense
| though!
| gsora wrote:
| 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 :-)
| PaulDavisThe1st wrote:
| What would the point be of storing a checksum of the original
| data if the compression technique is known to be lossy?
| wyldfire wrote:
| 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.
| aaaaaaaaaaab wrote:
| 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 -\\_(tsu)_/-
|
| [1] https://trac.ffmpeg.org/ticket/4628
|
| [2] https://trac.ffmpeg.org/ticket/4421
| mustache_kimono wrote:
| 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 -\\_(tsu)_/-
|
| 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.
| aaaaaaaaaaab wrote:
| >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.
| jhallenworld wrote:
| 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.
| hansjorg wrote:
| 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.
| ..
| Lammy wrote:
| 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)
| aaaaaaaaaaab wrote:
| If you're somewhat lucky, you'll be able to repair it with
| CueTools via CTDB.
| stevenwoo wrote:
| 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/
| giantrobot wrote:
| 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.
| comprev wrote:
| I have a fairly large collection of DJ and this tool sounds
| extremely helpful for management. Thank you!
| wongarsu wrote:
| 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.
| lake_vincent wrote:
| What are the reasons why not? What are the obstacles/drawbacks
| to the FLAC approach?
|
| I have no domain knowledge here, just curious
| lazide wrote:
| 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.
| samstave wrote:
| 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?
| CamperBob2 wrote:
| 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.
| detaro wrote:
| 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.
| aaaaaaaaaaab wrote:
| 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.
| fxtentacle wrote:
| usually frequencies too high to be heard.
| fuckstick wrote:
| 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.
| Gordonjcp wrote:
| 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.
| gspr wrote:
| > 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).
| afiori wrote:
| 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)
| fuckstick wrote:
| > 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.
| franga2000 wrote:
| 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).
| jansan wrote:
| I do not have very sensitive ears, but maybe an audio enthusiast
| can explain this to me:
|
| In the 80s and 90s some people were going crazy over HiFi, only
| the absolute high end products were just good enough. I remmeber
| seeing stereo systems for 50,000$ and more. CDs were already seen
| as inferior to records quality-wise, and speakers had to be huge
| if possible.
|
| Today Wifi speakers are all the rage. The music is downloaded
| (precompressed) and then sent over Wifi or Bluetooth with
| (sometimes very) limited bandwidth to a single speaker which has
| the size of a laptop.
|
| How does the audio quality compare? Is it like day and night? Or
| do the new multi room systems play in the same league as the old
| system that were used by enthusiasts? I often have the feeling
| that overall sound quality does not matter anymore as long as the
| bass is strong enough, but as I said at the beginning, my ears
| are not very sensitive.
| adgjlsfhk1 wrote:
| So to start, you should pretty much disregard anyone who thinks
| CD quality is worse than vinyl. CD quality is 16 bit, 44k
| samples per second, and despite some audiophile gear now that
| is 24 bit, 96k samples per second, ABX testing routinely fails
| to find a difference between them. As such, in terms of music
| quality and software quality, anything capable of delivering 16
| bit, 44k samples should be considered "perfect" (i.e.
| FLAC/CDs). There is some evidence that in studio conditions,
| people can hear a difference between high bitrate lossy
| compression and CD quality, but realistically, even Vorbis at
| 128kbps or other formats at 256kbps or higher will provide a
| very good listening experience.
| grumpyprole wrote:
| > even Vorbis at 128kbps or other formats at 256kbps or
| higher will provide a very good listening experience.
|
| Until it is resampled in the noisy OS mixer and/or lossy
| compressed again to be sent over Bluetooth. Very few ABX
| studies consider the effect of such modern "digital signal
| chains", especially transcoding. It's much better to start
| with FLAC.
| 01100011 wrote:
| CDs offer unquestionably better fidelity.
|
| But saying this without mentioning the loudness wars misses
| the main force behind vinyl's staying power.
|
| This is like making an argument for transistor guitar amps.
| They're better on paper, but tubes produce a type of
| distortion that is pleasing to many listeners.
| tmountain wrote:
| Most of the arguments in vinyl sounding better center on
| original masters being pressed directly to vinyl "biscuits"
| without an intermediate step while CDs go through a
| compression step before they are digitized. These days,
| that's rarely true. If original masters are used for too
| many high volume pressings, they wear out (physically), so
| the masters are often digitized before they go to vinyl.
| This sparked some controversy recently regarding a Michael
| Jackson repress with an ironic twist that nobody could tell
| the difference or noticed until the mastering engineer
| slipped up and let the cat out of the bag.
| Fronzie wrote:
| The first CD's were not that great, being effectively around
| 14-bit. Better D/A converters and noise-shaping during
| mastering greatly improved the sound quality. After that, the
| loudness wars destroyed it again.
| willis936 wrote:
| I feel it's important to explain why <44 kSamp/s sample rates
| are used. No matter what the digital audio signal should have
| no information above 20 kHz, but running ADCs far above
| Nyquist lessens the importance of the analog antialiasing
| filter. You don't need to worry about expensive caps and how
| they age if you sample at 192 kHz but filter to 20 kHz. This
| drives down the noise floor and increases linearity for
| essentially free.
|
| Please repeat this when people say "there's no reason to use
| sample rates above 44 kHz". While it's true for source
| material, it should be properly caveated.
| chongli wrote:
| I don't think that's giving people enough credit. Sure, if
| you master for CD to exploit as much dynamic range as
| possible (as is often done with high end classical music)
| then CD quality is truly amazing and vinyl can't even come
| close.
|
| But, a lot of popular music out there isn't mastered for that
| use case (high end ABX testing). On the contrary, there are
| tons of CDs that are extremely compressed (in the dynamic
| range sense) so as to sound as loud as possible on the radio
| [1]. If you compare one of these CDs with an earlier (or even
| contemporary) vinyl release which has been mastered correctly
| then of course the vinyl will sound better!
|
| Unfortunately, because we're dealing with a Wild West of
| media, new and old, floating around in the marketplace we
| don't have the luxury of a perfect ABX comparison, and so
| people will continue to buy and prefer old formats. It is for
| that reason that we can't dismiss them.
|
| [1] https://en.wikipedia.org/wiki/Loudness_war
| cbhl wrote:
| Do mixers still optimize songs to sound loud on the radio?
| I imagine these days most new music discovery happens via
| YouTube or Spotify.
| copperx wrote:
| I can't answer all of your questions, but I today we have
| AirPlay, which streams uncompressed audio to the receiver.
| Before that, the only option was Bluetooth or proprietary
| network codecs.
| hurflmurfl wrote:
| Isn't Airplay just another proprietary network codec though?
| jsmith99 wrote:
| The signal is digital until it gets to the speaker so there is
| no loss of quality after the initial encoding, which might
| itself be lossless. Some systems (eg Sonos) can stream lossless
| audio or even 24 bit 192 khz, which is certainly overkill.
| chrisseaton wrote:
| > The signal is digital until it gets to the speaker so there
| is no loss of quality after the initial encoding, which might
| itself be lossless.
|
| This ain't true - for example Bluetooth is lossy compression.
|
| 'Digital' doesn't mean lossless from the source.
| CyberDildonics wrote:
| You are conflating compression and verbatim copying which
| are two different things and obviously not what they're
| talking about.
| chrisseaton wrote:
| What they said:
|
| > The signal is digital until it gets to the speaker so
| there is no loss of quality after the initial encoding
|
| isn't true - the original encoding is decoded... and re-
| encoded, losslessly, by the Bluetooth protocol.
| djmips wrote:
| Who said they were talking about Bluetooth. It sounds
| like they were talking about a proprietary system like
| Sonos Wifi.
| chrisseaton wrote:
| > Who said they were talking about Bluetooth.
|
| Literally says 'Bluetooth' in the original comment.
| malermeister wrote:
| With some wireless systems (Bluetooth comes to mind), there's
| a lossy reencoding between playback device and speaker too!
| AshamedCaptain wrote:
| Lossy, but at >300kbps.... this is not going to be the part
| that introduces most artifacts.
| 2OEH8eoCRo0 wrote:
| In a choice between convenience and quality, convenience wins
| almost every time.
| zeroflow wrote:
| Those HiFi people are still there. And the products evolved
| with time.
|
| My guess: >90% of music consumers don't care about quality as
| long as it's good enough. What they care is ease of use. Why
| should they have a complicated setup and try getting their
| records in lossless FLAC when they can just go onto Spotify /
| Apple Music / YouTube and press play.
|
| I've seen lot's of people that don't even care that their audio
| has the intro parts when playing from youtube. So why should
| they care for HiFi.
| Bakary wrote:
| In some ways, audiophiles are the mirror image of this on the
| other end of the spectrum. Detectable improvements in sound
| do not matter and ABX testing is never mentioned in polite
| company. Why should they have a straightforward setup when
| they can purchase ever more arcane products and services to
| distance themselves from plebeians?
| rsynnott wrote:
| > I remmeber seeing stereo systems for 50,000$ and more.
|
| These absolutely still exist. What's changed, to an extent, is
| that they're a bit less fashionable; whereas in the 80s any
| self-respecting rich person needed a hifi that cost as much as
| a small house, today, this is largely the preserve of (rich)
| enthusiasts.
|
| The vast majority of people would have had relatively low cost
| stereo systems which were, by and large, far worse than their
| modern contemporaries, tho.
| wwarner wrote:
| I admit I'm basically in this category. But I recently saw
| Jazz at Lincoln Center Orchestra and was totally blown away,
| mostly by the writing, musicianship, creativity and courage,
| but also because of the best audio quality I've ever
| experienced, and it has me questioning my assumptions.
| cainxinth wrote:
| You can take a blind test and see for yourself if you can
| detect lossless audio from compressed:
|
| http://abx.digitalfeed.net
| ahofmann wrote:
| This test is, of course, limited to the equipment with which
| you perform it. The most important equipment by far is your
| own ears. I was 16 when the audience was blindly played the
| same song (by Michael Jackson) from vinyl, CD and DVD on a
| 1.5 million dollar system. At that time I could immediately
| tell which medium was being played. Half the people in the
| room were wrong and it was clearly due to the age of the
| audience. Meanwhile, I would probably also no longer be able
| to tell the difference. But If your audio system sucks, you
| will also have a hard time to Tell the difference in this
| Test.
| cainxinth wrote:
| I'm no spring chicken either and I don't have a million
| dollar setup, but with a pair of $100 Shure SE215, I can
| just barely make out which are lossy (usually). But it's
| not a big enough difference to concern me. I'm still plenty
| happy with a 320kps mp3.
| leokennis wrote:
| I have to say, just as a casual observation, that for the same
| money I can get a lot better sound now in 2022 than I could in
| 2002. Most low to midrange headphones (EUR50-EUR100) sound very
| acceptable and even the lower range Bluetooth speakers (EUR50)
| sound decidedly not terrible. In 2002 this money would buy
| headphones with no bass, shrill highs and muddy mids.
|
| Just compare the original earbuds included with the iPod to the
| wired EarPods that Apple sells now.
|
| Or compare the AirPods Pro ($249) to what the same amount
| (inflation adjusted) could get you 20 years ago.
|
| Of course there's still plenty of space on the high end, and
| still the higher you go the more you need to spend to achieve
| 1% better sound.
| karamanolev wrote:
| The main appeal of lossless, as I see it, is freedom - to
| reencode, transmit, store, transform audio (music) as you
| please, without any worry of loss. I'm not stuck with FLAC - I
| can use any fancy, new or old format and get the same music. I
| can create lossy MP3s, OGGs or anything else at a variety of
| bitrates appropriate for the case.
|
| Once you do lossless -> lossy, you're "stuck", unless you
| accept reencoding artifacts and those do add up to eventually
| be bad.
|
| I'm an audio enthusiast, have quality (but not excessive,
| triple digit prices) DACs, amps and everything else. I can't
| ABX 256kbps+ MP3s from lossless, but the above stands.
| TacticalCoder wrote:
| > CDs were already seen as inferior to records quality-wise,
| and speakers had to be huge if possible
|
| Doesn't sound very scientific to me.
|
| > How does the audio quality compare?
|
| Why compare with an old system from the 80s? I got to hear a
| friend's friend's modern audiophile setup. A dedicated room
| with Wilson Audio speakers (totally overpriced but amazing),
| high-end DAC, high-end amp... It was bliss. One of these $50K+
| setup but bliss. This is _nothing_ like a laptop, a soundbar or
| a Sonos.
|
| > Or do the new multi room systems play in the same league as
| the old system that were used by enthusiasts?
|
| I wouldn't be suprised they'd actually be better than these old
| systems. But they don't play in the same league as actual
| modern audiophile setups.
| nerbert wrote:
| What would be a modern audiophile setup?
| TacticalCoder wrote:
| > What would be a modern audiophile setup?
|
| What do you mean? What's the difference between an
| audiophile setup from the 80s GP was mentioning and one
| from today? Today you'd have a DAC, for a start. Maybe some
| DRC (Digital Room Correction software). Then amps have
| progressed tremendously. And so did speakers (newer
| materials).
|
| As for the setup I listened to: I'm no pro, I don't
| remember the details. I know the speakers were Wilson Audio
| but I don't remember the DAC nor the amp(s) brands: all I
| know is it was high-end stuff costing money I'm personally
| not willing to put in an audio setup. But it did sound very
| good.
| dylan604 wrote:
| >Doesn't sound very scientific to me.
|
| From my experience with them, you kind of just summed up the
| HiFi/audiophile core. I've spent waaay too much time with
| audio engineers, recording engineers, etc from edit bays to
| sound stages. Yes, there are now things that I can hear
| because they pointed it out to me, but until then, I was
| perfectly content with my head in the sand of not-knowing.
| However, while I agree there are certain things that can make
| a difference, the tendency for the absurd always seems to
| take hold.
| m-p-3 wrote:
| Personally I use FLAC for archiving purposes, to preserve a
| copy of my physical CDs. They're available in my home Plex
| server, but they'll get converted to a lossy format if synced
| to save some storage space on that device.
| TacticalCoder wrote:
| > Personally I use FLAC for archiving purposes, to preserve a
| copy of my physical CDs.
|
| Same, but at home I also play directly the FLAC files (laptop
| / DAC / amp / floorstanding loudspeakers). They're not that
| much bigger than 320 kbps mp3 files.
|
| I convert to lossy for my car, which takes mp3 files but not
| FLAC.
|
| I used to collect mp3s back in the Napster days. My HDD was
| maybe 40 GB back then (?), maybe not even that. Nowadays FLAC
| files size aren't a concern. I think a screenshot of my
| screen takes more room than a song FLAC encoded.
| dsr_ wrote:
| The cost for high quality plummeted, especially in audio
| storage, playback, and amplification. That was 1980-2010. The
| technical advances were not particularly big in microphones,
| but very big in analog-digital conversion, digital storage,
| digital editing, and digital-to-analog conversion.
| Amplification was rejuvenated by switching power supplies and
| class D amplifiers starting in 1996. The availability of high
| quality measurement techniques vastly improved the state of the
| art in speakers since 2000 or so.
|
| Meanwhile, mass-market audio has gotten better but not
| consistently. The speakers are usually the limiting factor for
| quality: you can have at most any two of small speakers, deep
| bass, or volume for a given power budget. Lots of consumer
| systems go for small speakers and don't have either deep bass
| or high volume.
|
| Does sound quality matter? That's an individual choice. It's
| available to you at a much lower cost than ever before in
| history.
| netr0ute wrote:
| Audio quality has gotten a lot better over time as speaker and
| player technology improved, so now cheap mainstream stuff could
| be equal to high end back then.
| layer8 wrote:
| Not quite, the weakest link are the speakers (and room
| acoustics), and cheap speakers -- which the large majority of
| "mainstream" speakers are -- still suck today as they did in
| the 90s.
| netr0ute wrote:
| > and room acoustics
|
| Interestingly, a study suggests that room acoustics don't
| negatively affect the sound of good speakers, and what that
| means is that for listening, acoustics don't matter as much
| as they do for recording.
| eropple wrote:
| A lot of mainstream speakers are pretty bad, but I tend to
| think that once you get above a couple watts the quality-
| for-money tatto ratio goes up quite a bit.
| jsbg wrote:
| tl;dr: the algorithm splits the audio into blocks (default is
| 4096 samples per block). Then a polynomial is used to approximate
| the wave for the block, and residuals are calculated for each
| sample by subtracting the approximation. The residuals, because
| their magnitude is smaller than the original signal, require
| fewer bits to encode. Hence the smaller file without loss of
| information.
| black_knight wrote:
| As always with compression there is no magic. There are wav
| files that are smaller than the equivalent flac file (perhaps
| even the majority of possible WAV files are shorter than their
| equivalent FLAC). But it so happens that the sounds we actually
| want to store are very well approximated by polynomials.
| cryptonector wrote:
| Plus the use of Rice codes for encoding the residuals in as few
| bits as possible.
| drawingthesun wrote:
| Would applying a lossless compression algorithm to the data
| such as zip or 7z after the algorithm you describe reduce the
| file even size even more?
|
| Wondering if FLAC already does this or if such a feature could
| be added?
| tgv wrote:
| These methods perform poorly on audio, so even worse on
| compressed audio. Just try it on a wav and a flac file.
| aidos wrote:
| Nice. Not dissimilar from what jpeg2000 does (from memory -
| correct me if I'm wrong!). They use the previous pixel values
| in order to "guess" the next value and then store the delta,
| which tends to be a smaller number on average, giving better
| compression.
| mistrial9 wrote:
| proximity in a 2D image has neighbors in north-south-east-
| west (NSEW) on a 2D grid, not just pixel neighbors per-
| scanline (row of bytes); proximity in a sound file has
| harmonics and transitions of some plural set of signal, but
| the sound file neighbors are roughly at a point in time.
| corrections welcome
| robotresearcher wrote:
| True. The fact of locality in real-world 2D images means
| you can predict a pixel's value by picking any neighboring
| pixel, or indeed any nearby pixel, with worsening
| performance with L2 distance. There's no reason I can think
| of to prefer a direction, except for convenience in the
| data structure.
| derefr wrote:
| Curious to me why only such a simple representation
| (polynomial) is used for the approximation. 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. wavelet LUTs as your primitive
| (plus maybe a larger block size)?
|
| Are there other, more advanced lossless encodings that do this?
| And if so, why didn't they catch on compared to FLAC?
|
| For 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.)
|
| (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. 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. Possibly
| made sense in the late 90s, when a PC's RAM wasn't much larger
| than five minutes of uncompressed audio. Doesn't really make
| sense today. Maybe we're due for a new lossless audio
| encoding?)
| sdenton4 wrote:
| FLAC can use polynomials or lpc, as described in the article.
|
| I'm curious if you'd gain anything by doing an mdct and then
| modeling in the frequency domain and then storing the
| residuals... Lots of the frequency channels will usually have
| much lower energy, so the residuals wind up being easier to
| store.
| dspig wrote:
| Diminishing returns - the polynomial is already good relative
| to the unpredictability of the waveform. Adding degrees of
| freedom to the analyzed/predicted waveform shape at some
| point needs as many bits to store as a larger residual signal
| would have.
| hcs wrote:
| > 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?
|
| It's not "regular lossy", but WavPack does allow separating
| lossy from the residual in hybrid mode. I think this is
| rarely done with DCT-based stuff because there's so much
| potential imprecision in the decoders.
| magicalhippo wrote:
| > I think this is rarely done with DCT-based stuff because
| there's so much potential imprecision in the decoders.
|
| Is this why h.264 and friends are specified in terms of how
| it's decoded?
| [deleted]
| Cupertino95014 wrote:
| My pandemic project was to flac-ify _all_ my music, including the
| vinyl records. It still fits on a microSD card, so the phone now
| has everything.
|
| It's funny how often people still assume "on the computer" means
| "MP3." I don't know why you'd put up with _any_ loss of quality
| anymore, even if you personally can 't hear the difference.
| wheels wrote:
| I don't have a crazy large music collection, and mine is 85 GB
| of 192 kbps MP3s. With FLAC that'd be 250-ish GB of music.
| That's a significant chunk of most modern SSDs.
|
| Why _would_ you use 3x the storage space if you can 't hear the
| difference for a non-trivial percentage of your available
| storage? Literally, by definition, according to your own terms,
| it serves no purpose.
|
| I'm a musician and audio developer, and it's only really in my
| own music, that I've listened to over and over again while
| creating it, that I notice the degradation in a 192 kbps MP3 -
| and occasionally in the high-hats of CDs that I listened to
| hundreds of times in high school.
|
| FLAC's great, and definitely serves a purpose, but I use it
| mainly for archives, not for casual listening.
| aqwsde wrote:
| For god's sake, there is opus. I just don't understand, why
| people stick with their 90s codecs.
| wheels wrote:
| Do you mean Ogg Vorbis? Opus is a codec for speech.
|
| I hate pulling rank so fiercely, but I literally wrote the
| second (i.e. first non-reference) implementation of the Ogg
| container format (which Opus, Vorbis and sometimes FLAC
| use). I know these codecs.
|
| Ogg Vorbis and AAC hit similar levels of quality as a 192
| kbps MP3 around 160 kbps. (That actually depends a fair
| amount on the MP3 encoder. The LAME VBR is particularly
| good.)
|
| But I have an 11 year old receiver and a 12 year old car
| that can't play them. Hell, even iTunes can't without
| third-party codec plugins. MP3s are about as universal as
| it gets. Being able to play my files everywhere is pretty
| high up on my list of concerns.
| Cupertino95014 wrote:
| MP3 is indeed universal, and iTunes doesn't support FLAC.
| However, on my Mac there are any number of third party
| players that do (e.g. I have Elmedia Player at the
| moment), and on the Android almost every music player app
| supports FLAC.
|
| I don't know about an iPhone. I assume you can find apps
| that support it.
| blibble wrote:
| > With FLAC that'd be 250-ish GB of music.
|
| at current prices that's about $25 of SSD
| doubleunplussed wrote:
| One cannot simply add more SSDs to one's laptop, regardless
| of price.
| Cupertino95014 wrote:
| But one can buy a multi-TB drive that plugs into the
| laptop's USB 3.0 port. The "multi" part of it keeps
| getting larger, for the same price.
|
| And you can keep an extra one at another site in case
| your house burns down.
| wheels wrote:
| It's about $50 for a Macbook Pro. And I have my music on 4
| devices. Sure, I could throw $100-200 at music storage that
| I can't hear any difference in, but why the fuck would I?
| Again, this is golden-speaker-cables stuff.
| Cupertino95014 wrote:
| Why would I use it? Because, as I said, it all fits on a
| microSD card (and that's a 256GB card, which is not the
| largest you can get). Yours would fit on the larger-sized
| card with plenty of space left over.
|
| No, I did not say "it serves no purpose." Those are your
| words. And I didn't say I can't hear the difference, either,
| I said I don't care if I can't.
|
| My purpose is "you don't throw away information."
| wheels wrote:
| Just to add to the fun, here's the Xiph founder arguing for
| lossy data formats:
|
| https://people.xiph.org/~xiphmont/demo/neil-young.html
|
| The arguments for lossy codecs vs. dithering / bit
| reduction aren't identical, but it's a pretty good
| indictment of the _SAVE ALL THE BITS_ argument. On the same
| domain as the parent article.
| wheels wrote:
| Sorry, I meant that not being able to discern any
| difference is literally the definition of useless.
|
| And MP3s get stored on a lot of things that aren't SD
| cards, so that's a pretty weird metric.
|
| But you're getting dangerously into gold-audio-cable-and-
| tinfoil-hat territory. Most people (including me, literally
| an audio expert) can't hear the difference in most cases so
| you're arguing for the increased space, and significant
| cost based solely on some notion of purity. That makes
| sense for archives, where they're being preserved for
| posterity and potential future processing, but not for
| casual listening.
|
| Would you prefer that all websites served you only PNGs?
| Cupertino95014 wrote:
| Gold audio cables? Now you're talking tinfoil hat
| territory :)
|
| It IS "archival." Maybe when I'm dead and gone, so
| distant relative will be listening to this. Maybe they'll
| be able to hear the difference. Who knows?
|
| I don't think the SD card is a weird metric at all. It
| fits in the phone, so even if, worst case, I'm traveling
| and rent a car (assuming it has Bluetooth), I still have
| all the music.
|
| I'd gain absolutely nothing by having them as MP3s, and
| the price of a TB is only going to keep dropping.
|
| Of course, I'd also gain nothing if _you_ switched to
| FLACs. You perceive different tradeoffs than I do, so
| that 's fine.
| wheels wrote:
| I still listen to my dad's classic rock records from the
| 60s and enjoy the hell out of it. But they sound like
| shit. ;-) If anyone someday down the line inherits your
| FLAC collection, they'll be listening to it out of
| nostalgia, not for the pristine audio quality.
|
| You started with "I don't know why you'd..." and the
| answer is "because it's a waste of money" and "because
| you (mostly) can't hear a difference" and "because they
| work in my car".
|
| As a side note, I have a phone that _does_ take an SD
| card (in part because I like having my complete music
| collection there), but most people don 't.
| Cupertino95014 wrote:
| > If anyone someday down the line inherits your FLAC
| collection, they'll be listening to it out of nostalgia,
| not for the pristine audio quality
|
| I beg to differ on that. The 30s jazz records that are so
| wonderful musically still sound like shit nowadays.
| That's a major deterrent to playing them.
|
| > I have a phone that does take an SD card ... but most
| people don't.
|
| I can't say about the numbers, but I didn't have much
| trouble finding a phone that took them in April 2021.
|
| In general terms: over the last 50 years, it's never been
| a _terrible_ move to waste CPU cycles or disk storage.
| Especially if it 's a permanent choice.
| PapuaNewGuinea wrote:
| Lossy codecs suck at gapless playback. Some have support via
| vendor-specific extensions, but it's hit or miss whether a
| particular player will support it. With FLAC you can always
| be 100% sure that your album is gapless.
| moffkalast wrote:
| Because my music collection would otherwise take up more space
| than the 128 GB of internal storage my phone has? FLACs are
| nice, but they're also a few MB per track.
|
| Maybe in another decade.
| Cupertino95014 wrote:
| Check out microSD card prices.
| mkl wrote:
| > FLACs are nice, but they're also a few MB per track.
|
| So are MP3s, unless you compress them to crap. FLACs are more
| like low 10s of MB, about 2.5x high quality MP3s in my
| experience.
| DiogenesKynikos wrote:
| For most music, it's already very difficult to notice any
| degradation at 128 kbps with modern codecs/encoders.
|
| You have to know what to listen for, and even if you do,
| why should you care? It's a small price to pay for being
| able to store several times as much music on your phone, or
| for saving on bandwidth while streaming.
| mkl wrote:
| Sure, but even 128kbps is about 1MB/minute, so still "a
| few MB per track".
| MrStonedOne wrote:
| bretbernhoft wrote:
| I've only ever used .WAV and .MP3 formats. What would a .FLAC
| file format be used for?
| Snd_ wrote:
| It's like a zip, but for audio. Uncompresses to the exact
| original.
| dddddddd111 wrote:
| andai wrote:
| wav but smaller
| LocalH wrote:
| Lossless compression of PCM audio
| redcalx wrote:
| WAV is uncompressed. MP3 is highly compressed, but lossy. FLAC
| is compressed and lossless. If you wanted to store lots of
| master copies of audio, you could use WAV or you could reduce
| storage space by using FLAC instead.
| samstave wrote:
| But you cant (up)convert WAV to FLAC? right? so if your
| source is WAV or MP3, FLAC is irrelevant?
| alexanderh wrote:
| What? Most all FLAC is created (converted) from a WAV
| source. If your source is MP3, then yes, FLAC is
| irrelevant... But FLAC is basically a lossless compression
| format for WAV.
|
| I'm really confused by what you're talking about lol...
| especially "up"convert...??? WAV is the ultimate lossless
| audio on PC. It really doesn't get any better than WAV.
| There is no "up" from WAV. FLAC is a compression format for
| WAV, that does not lose any data. The output of FLAC will
| be identical to the WAV file, even though its compressed.
| MP3 is a compression format for WAV that loses data, and
| will not be identical to the original WAV file.
| hcs wrote:
| PSA: If you want to recreate the original file (WAV,
| AIFF, etc), including metadata, you should use the
| --keep-foreign-metadata switch to flac, otherwise it only
| preserves what's needed for the audio.
|
| https://xiph.org/flac/documentation_tools_flac.html#flac_
| opt...
| Maursault wrote:
| WAV this and WAV that.
|
| In 1988, Apple developed the Audio Interchange File
| Format (AIFF), which is uncompressed pulse code
| modulation (PCM). PCM is what is stored on CDs, so any
| Mac with a CD-ROM drive attached will recognize the PCM
| information on Red Book audio CD's as AIFF files.
|
| Inexplicably, 3 years later, Microsoft and IBM developed
| the Resource Interchange File Format (RIFF) in 1991, of
| which the WAV format is one implementation. RIFF doesn't
| store PCM. Instead it stores various formats of data in 4
| byte "chunks."
|
| Depending on the audio file format specified, one can
| always distinguish a Windows user from an audio
| professional (or a Mac user), because since about 1990,
| the vast majority of professional audio recording
| (tracking, mixing and mastering) studios have been
| exclusively Mac shops, including such greats as Skywalker
| Sound and Abbey Road Studios.
| hcs wrote:
| https://en.wikipedia.org/wiki/Interchange_File_Format
|
| All these formats, IFF, AIFF, and RIFF, use named chunks
| for organization, and store PCM basically the same way,
| though there are other payloads possible.
| hurflmurfl wrote:
| WAV is the original lossless audio file. FLAC is just a
| compressed version of that file (think of it as .zip).
|
| MP3 is more like an edited version of the original where
| "extra fluff" is removed from the audio in a way that you
| can still hear the important bits. And then compressed for
| further space savings.
|
| Obviously, there is no point in converting MP3 to FLAC
| since when the original lossless audio track was MP3'd , it
| lost some of the audio information, so you'd only be
| changing the compression algorithm, I imagine.
| cryptonector wrote:
| https://www.lalal.ai/blog/difference-between-audio-formats-m...
| TacticalCoder wrote:
| In addition to what others have said (FLAC is lossless but
| compressed, and about 50% smaller than WAV), FLAC (plus a few
| other tiny files) is also the de facto format for archiving
| audio CDs (it can do other quality than CD quality, but it's
| mostly used to backup CDs).
|
| When you rip one of your CD, a good ripper shall verify that
| your rip is 100% bit perfect (by verifying that the hash of
| your rip matches an online database of hashes of CDs ripped by
| other people). These rippers typically do rip to FLAC.
|
| FWIW on Linux I've had good luck with "whipper" in the past
| (haven't ripped any CD that recently) [1]
|
| [1] https://github.com/whipper-team/whipper
| layer8 wrote:
| Lossless compression to around 60% of WAV size. Also more
| widespread support for tags than with WAV. So even if you don't
| particularly care about the space savings, converting to FLAC
| could still be beneficial.
| scns wrote:
| 50% at the highest setting.
| layer8 wrote:
| Depends on the audio content, not all genres are equally
| compressible. The average tends to be above 50%.
| Severian wrote:
| Being able to convert back to a 1:1 format of the original
| source.
| armchairhacker wrote:
| I wish apple supported FLAC. There's an amazing free tool to
| convert to/from ALAC (https://tmkk.undo.jp/xld/index_e.html), but
| still: some players only support FLAC and some ALAC and sometimes
| you can't transfer songs in either format because of the no
| overlap between source/target.
| [deleted]
| esperent wrote:
| I'm always mystified when someone says they wish their _general
| purpose computing device running a Unix based OS_ supported X
| feature.
|
| How can an Apple device not support FLAC? Are they really that
| locked down that you can't do something basic like install a
| codec?
| CharlesW wrote:
| > _How can an Apple device not support FLAC? Are they really
| that locked down that you can 't do something basic like
| install a codec?_
|
| You can't install a codec globally on iOS, but there are
| many, many player apps that support FLAC:
| https://www.igeeksblog.com/best-music-player-apps-for-
| iphone...
|
| For folks who think Apple Music is the best music app for
| iOS, it's not difficult to convert songs, albums, or whole
| music libraries to ALAC.
| pier25 wrote:
| Anyone knows if FF has solid FLAC support now?
|
| I know a couple of years ago it used to be flaky. Eg:
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1528265
| shoghicp wrote:
| Still flaky with double ID3 tags (front/back) or issues parsing
| metadata (so it fails decoding), but the issues with variable
| block size were solved. Most FLAC I handle on a large system
| play fine.
|
| There are other issues related to streaming the FLAC via Range
| requests depending if it is WebAudio, <audio> or directly in a
| tab, however this applies to all audio/media in general.
| pier25 wrote:
| > _There are other issues related to streaming the FLAC via
| Range requests_
|
| Could you share more info on that?
| brnt wrote:
| Flac has Flac tags, how did Id3 get up in there?
| lifthrasiir wrote:
| ID3 is format-agnostic so it shouldn't be no surprise to
| see it in flac. Even the linked article mentions that flac
| does recognize and skip ID3 tags.
| brnt wrote:
| You have to go out of your way to add them though. It's
| not standard.
| shoghicp wrote:
| A lot of tagging programs add them as they just get
| appended or prepended to the file regardless their content.
| Sometimes one program reads a format but writes in the
| other, I have personally found a FLAC in the wild with
| ID3v2 at the front, ID3 at the back (corrupt) and FLAC
| metadata as well. The FLAC metadata inside was wrong, the
| valid one was outside at the front (sadly it was a broken
| JIS encoding).
|
| There is no sane approach to media. Between legacy formats,
| legacy tagging, and all kinds of implementation specific
| bugs, you are in for a ride if you want to cater to more
| than one decoder out there :)
| doublepg23 wrote:
| The videos Xiph did a while back are excellent for understanding
| some digital audio concepts (though it's somewhat dense with
| jargon).
|
| https://www.xiph.org/video/
___________________________________________________________________
(page generated 2022-09-05 23:00 UTC)