What is Reddit's opinion of FLAC?

From 3.5 billion Reddit comments

While your observation is correct, the Flac format only supports this inter-channel decorrelation for stereo audio. For any other number of channels, it cannot do any decorrelation at all, not even for the left/right channels. See the channel assignment field in the frame header.

Actually no not according to the hydrogen audio tests. ALAC was clocked in at ~160-225 times real time decode while FLAC clocked in at ~410-450 times real time decode. If ALAC files are larger the only metric it may be better is encode but seriously who cares about encode you do it once.

Flac was open since day one, it has awesome metadata, such as embedded album art and lyrics support. It is seek-able, streamable and error resistant. It also has hardware support and is default in Windows 10 and Linux systems. Apple seriously has little to no excuse except NIH syndrome(Not Invented Here).

From https://xiph.org/flac/license.html:

>FLAC is a free codec in the fullest sense. This page explicitly states all that you may do with the format and software.

>The FLAC and Ogg FLAC formats themselves, and their specifications, are fully open to the public to be used for any purpose (the FLAC project reserves the right to set the FLAC specification and certify compliance). They are free for commercial or noncommercial use. That means that commercial developers may independently write FLAC or Ogg FLAC software which is compatible with the specifications for no charge and without restrictions of any kind. There are no licensing fees or royalties of any kind for use of the formats or their specifications, or for distributing, selling, or streaming media in the FLAC or Ogg FLAC formats.

They are popular, period. Matroska aka mkv is a quality container and flac is an extremely popular lossless audio codec. The problem is probably that they are free and open source.

But then lets talk about AC3, avi, or wmv, also typically not supported by Apple. Without VLC a lot of video formats wouldn't be supported at all.

Let's start with some basics.

Terminology: Kbps= Kilobits per second

ALAC= Apple lossless audio codec

FLAC= Free lossless audio codec, further reading https://xiph.org/flac/ "an audio format similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works, except with FLAC you will get much better compression because it is designed specifically for audio"

FLAC stands out as the fastest and most widely supported lossless audio codec, and the only one that at once is non-proprietary, is unencumbered by patents, has an open-source reference implementation, has a well documented format and API, and has several other independent implementations.

Wav= CD Quality 1411Kbps

Aiff= CD Quality 1411Kbps

For Wav think PC standard, Aiff Apple standard, both are identical, just packaged differently and both can be used by both platforms, format wars kind of like Beta vs. VHS tape.

FLAC= around 1000Kbps

ALAC= around 1000Kbps

Both FLAC and ALAC can be uncompressed to Wav/Aiff

MP3= lossy can be as low as 32kbps to as high as 320kbps

AAC= Apple's version of MP3, can be as low as 32kbps to as high as 320kbps

Can actually be up-converted to FLAC, ALAC, or even Wav/Aiff but no information is uncompressed, remember mp3 and aac are lossy meaning information is taken out and lost forever. If you up-convert to FLAC, ALAC or Wav/Aiff you just add a bunch of 0000's making a bigger file size but no increase in audio quality.

> I don't care about decompression runtime efficiency for audio. I'm not sure who does.

Well, basically anyone with constrained CPU power and/or power consumption (battery life) does. So, basically anyone playing audio on a mobile device. So... nowadays, basically nearly everyone ;)

I got the "nearly constant" one from slides I can't find now, it was a few years ago when I was majoring in Electronics/Telecommunications. There was this neat comparison, coupled with a graph of decompression time (y) vs compression rate (x). While most audio codecs sloped "upwards" in time considerably between data points as compression level rose, the line drawn between points was distinctly flat.

But similar claims can be found on right on the FLAC website.

> FLAC stands out as the fastest and most widely supported lossless audio codec

and

> FLAC is asymmetric in favor of decode speed. Decoding requires only integer arithmetic, and is much less compute-intensive than for most perceptual codecs. Real-time decode performance is easily achievable on even modest hardware.

EAC is a brilliant piece of software and I've been using it forever.

Give the manual a read, set it up properly (not that difficult) and it will give you bit-exact rips every time. It does not support encoding into FLAC natively, but you can download a command line encoder from xiph and configure it as user-defined encoder.

lossless and open source audio file format. you get around 60% smaller file, no loss in the audio quality and decompresses to the original audio data. which is pretty great.

BUT there's a vinyl-like community around it who think if you listen to any other format you're some kind of monster.

Their website is here if you want to get deeper.

FLAC works differently:

„With FLAC you do not specify a bitrate like with some lossy codecs. It's more like specifying a quality with Vorbis or MPC, except with FLAC the quality is always "lossless" and the resulting bitrate is roughly proportional to the amount of information in the original signal.“

FÖSC FAQ

The bitrate is variable, it cannot be set.

> but how do I losslessly convert my entire music library to other formats?

FLAC

I've ripped my whole CD collection using flac, which is a compressed lossless format. From there I can go anywhere.

Yes it is Apple's fault, and the benchmarks show it isn't even close for CPU usage. FLAC is technically superior in almost every way. Has the best hardware support, reliability / error tolerance. It has the best open tools to verify and protect the integrity of the files. As a lossless format it truly is the gold standard that should really piss Apple users off that they don't have access to. Even Blackberry, can play FLAC files, RIM/ Blackberry has support for the best Lossless format and Apple doesn't. It is quite pathetic on Apple's part that RIM / Blackberry bested them on that front.

Flac is a compressed format. The file size difference might be due to different compression level used https://brianli.com/flac-compression-level-explained/

It could also be some optional fields used by the encoder, such as padding and comment fields which might not be picked up by the metadata editor you’re using https://xiph.org/flac/format.html

Song rip from CD using year 2000 version of Flac encoder will be different in size from one that is encode using current version of Flac encoder.

Oh, interesting. According to https://xiph.org/flac/features.html, the FLAC file format does support cover art. The docs describe 7 types of metadata blocks, one of which is

> PICTURE: This block is for storing pictures associated with the file, most commonly cover art from CDs. There may be more than one PICTURE block in a file. The picture format is similar to the APIC frame in ID3v2. The PICTURE block has a type, MIME type, and UTF-8 description like ID3v2, and supports external linking via URL (though this is discouraged). The differences are that there is no uniqueness constraint on the description field, and the MIME type is mandatory. The FLAC PICTURE block also includes the resolution, color depth, and palette size so that the client can search for a suitable picture without having to scan them all.

So it sounds like the issue is with the apps and not the file format.

[info] Available formats for rMkmGqeaOOI: format code extension resolution note 140 m4a audio only DASH audio 128k , m4a_dash container, mp4a.40.2@128k, 4.01MiB 17 3gp 176x144 small , mp4v.20.3, mp4a.40.2@ 24k 36 3gp 320x180 small , mp4v.20.3, mp4a.40.2 43 webm 640x360 medium , vp8.0, vorbis@128k 18 mp4 640x360 medium , avc1.42001E, mp4a.40.2@ 96k 22 mp4 1280x720 hd720 , avc1.64001F, mp4a.40.2@192k (best)

FLAC is barely two decades old and only supports 8 channels (per stream), metadata, lossless compression and both codec and toolset are free, so widespread adoption may take a while due to those enormous barriers and costs.

​

Are you inviting us to your place to listen to your records then compare them to the YouTube stream? I'll bring my Diamond Rio 500.

​

This details how MP3 (which is a lossy compression technique) works

http://www.math.utah.edu/~gustafso/s2012/2270/web-projects/Guckert-audio-compression-svd-mdct-MP3.pdf

I would compare this information to how these codecs (which are lossless) function

http://www.bobulous.org.uk/misc/lossless_audio_2006.html

with flac being my favorite

https://xiph.org/flac/format.html

Best part about this process is that it's very noticeable when you hear the difference between a 96bit encoded mp3 versus a 320bit encoding mp3 because the 96bit encode has more 'loss' but neither will have as much fidelity as a wav or a flac file

The same can be said about the difference between a jpg at low image quality versus high image quality versus a tif file

I personally just use metaflac to add replay gain tags. Doing it in bulk with either a simple combination of parallel and find, or when tagging music with Picard using the replay gain plugin.

As for players, I don't know of any worthwhile player that does not support replay gain.

edit: wrong link

This might be interesting for you:

> Why do the encoder settings have a big effect on the encoding time but not the decoding time?

>It's hard to explain without going into the codec design, but to oversimplify, the encoder is looking for functions that approximate the signal. Higher settings make the encoder search more to find better approximations. The functions are themselves encoded in the FLAC file. Decoding only requires computing the one chosen function, and the complexity of the function is very stable. This is by design, to make decoding easier, and is one of the things that makes FLAC easy to implement in hardware.

You can think of it as finding a equation for given points: Lets say you have the points (x,y): (-1,2),(0,1),(1,2). For encoding you need to find the parameters a,b and c for f(x)=ax^(2)+bx+c. A valid solution would be a=1, b=0, c=1.

Once found you can calculate the y values just given the x values and f(x):

• f(-1)=2
• f( 0)=1
• f( 1)=2

It is easy to decode the values but takes time to find a fitting function and even long equations are easy to compute.

FLAC is lossless, so converting them will not cause any issues at all. It will just give you the original wave back.
For conversion I'd use foobar2000, but I'm already using that as my media player. You could also just download the codec and convert with a script. Or Audacity should work.

FLAC just compresses a PCM signal, the same you have in wave and supports from 1 to 8 channels (thus 5.1 is possible), bit dephs from 4bit to 32bit and up to 655350Hz. You could encode signals up to 327,675 Hz with that. So extreme bitrates are possible. taken from xiph.org

If you have audio files with 5.1 surround at 24bit and 96kHz (compression factor 0.7) you could easily get 9676,8 kbits^-1.

Back to your question: For recorded audio cd quality is enough for the human ears according to the sampling theorem. You don't need frequencies higher than 20kHz (therefore 44.1 kHz sampling frequency, slightly above the needed 40KHz for convenience) and not more than 16bit (gives you around 96dB signal to noise ratio). If you have two channels of that encoding you get 987,84 kbits^-1 with a compression level of 0.7. The compression level depends on the level you chose when encoding ( "8" is the maximum) and the song itself. A song with a lot of silence can have lower bitrates than one with much noise or loud sounds. After decoding you always get the original PCM signal back. Just imagine FLAC like a zip compressed folder, just specialized for audio. You put in a word document and the zip file is smaller than the original .doc file. You decompress it and you get the original file again.

TL;DR

>I [want] to know if there is anything I can do to tweak the operating system to get the best possible audio quality, like the settings located in Windows 7 and 8.1.

Gah. To get the best possible audio quality you tell the operating system to keep its nose out of your audio streams, and you store/serve everything as FLAC files.

https://xiph.org/flac/

I know EAC and I believe foobar2000 both use the FLAC encoder from the FLAC website, (especially since the foobar2000 encoder component installer was updated a few weeks after the new FLAC encoder release).

There are other FLAC encoders, including the one inside FFMPEG and FLACCL... but I doubt you are using them.

I don't think you need shntool in this case, you can just do

flac -o newfile.flac [other options] file1.flac file2.flac

directly with the flac.exe.

I know that MP3 and FLAC support ReplayGain, which is a lossless track equalisation method that doesn't modify the audio. MP3 uses Mp3Gain and FLAC has its own way to apply that (see this document). It basically tags on some metadata to the audio file without touching the actual data. Compatible audio players will then read those tags and apply the appropriate gain automatically.

Gain applied in this way should be infinitely changeable and reversible, AFAIK.

you can also find the original sources of all files with a simple search (they are all free)

• flac.exe: https://xiph.org/flac/download.html
• lame.exe: https://lame.sourceforge.io/
• wavepack.exe: https://www.wavpack.com/downloads.html

etc.

The FLAC subset specifies:

>The Rice partition order in a Rice-coded residual section must be less than or equal to 8.

As you're allowing the rice partition order to go up to 15, this isn't necessarily being met causing the error. Add the -lax parameter if the consequences of not meeting a FLAC subset are acceptable.

Out of curiosity, why are you fiddling with all these parameters?

I just discovered this from a post on r/hfy and I'm in love. Will definitely be checking out some of the albums on IA.

It would be very cool to see these archived from tape in a lossless codec like FLAC.

> Fast: FLAC is asymmetric in favor of decode speed. Decoding requires only integer arithmetic, and is much less compute-intensive than for most perceptual codecs. Real-time decode performance is easily achievable on even modest hardware.
https://xiph.org/flac/features.html

There's probably a good explanation of this somewhere, but it kinda sounds like they've intentionally made decoding less complex.

https://en.wikipedia.org/wiki/FLAC
https://en.wikipedia.org/wiki/MP3
^ there seems to be rather more detail on MP3 encoding/decoding despite being a limited overview

I actually doubt that it's a float, since that indicates a need for decimal precision, which doesn't really apply to a sinewave - it doesn't care about decimals when you think about it.

Anyways, on windows, it looks like the flac format is actually an unsigned int32, or uint32. I found more info to back that up here

And here in an flac api documentation.

Developer rant: I wouldn't be surprised if it was the same on Linux. And regarding data transfer over cables, the standard protocols require a header over every packet that defines the length and depth of the data being set (ie the rate and bit-depth). It's up to the receiver to do with it what they will. If I wanted to read a 32-bit number as a float, there's nothing stopping me from it. But it is technically less performant than a straight short, integer, or long. So looking at that, it also makes sense that float is not used.

Now I could be wrong still, but the brief googling I did above seems to agree that floats are not used :)

Hi,

I'm on Windows and use Exact Audio Copy. When I started ripping CDs, it was the only solution to reliably rip audio CDs (i.e. bit-exact copies) and I simply stayed with it.

These days there are alternatives, e.g. CUERipper, but I haven't tried them.

I rip all my CDs into a single-file FLAC and a CUE file (track index + some metadata). EAC supports FreeDB, CUETools and GD3 for tagging. GD3 costs a little bit for lifetime access, I think it's well worth it. I do use EAC to retrieve metadata, but the only metadata I set on extraction/compression is total track number.

When the extraction and FLAC compression is done and if I'm not happy with the cover found by EAC, I use Album Art Downloader to find a better one.

Finally, I make sure the CUE file is properly encoded in UTF-8 (if album or track names use non-ASCII characters) and use metaflac.exe to import the CUE file, set tags using the CUE file and import the cover image into the FLAC file. Metaflac.exe is a part of the official FLAC tools suite, found on Xiph site.

If I want to add any other tags, I do it from Foobar2000.

Finally, my bundle for each CD is:

• FLAC file with CUE file and cover image imported
• CUE file
• cover image
• EAC log file

I keep CUE and cover image files separately, since some media players don't understand embedded CUE files and covers.

I used to RIP multi-CD albums into a single FLAC file (rip+join), but it was too much faff. Nowadays I just rip each CD separately, but tag each FLAC file as CD 1 of X, and my main media player (Kodi) understands these tags and shows those CDs as a single entry in the media library.

EDIT: Posted in the middle of writing the reply :-)

The reference implementation can convert 48 kHz files just fine.

Also, a friendly reminder that 24-bit audio is useless unless you're a record producer.

No, there is an actual FLAC format specification that should allow you to implement an independent encoder and decoder, either in library form or as straight executables.

To actually provide an answer to why the metadata theory is poppycock: The FLAC metadata blocks all precede the frames data. Unless the one who writes the decoder is fully braindead, the metadata blocks are read exactly once - on initial loading of the file, and parsed into a structure. (Here is the FLAC stream specification). The metadata always precedes the audio frames.

There are some differences in how FLAC behaves contra WAV, unless you decode the entire stream in memory, but none of these actually affect sound quality. If you decode the FLAC on the fly, instead of pre-decoding the entire file, you cannot seek to arbitrary points in the FLAC, but you need to seek to the start of a particular frame.

Frames are always larger than 1 sample (From reading the spec, the smallest possible frame with valid subframes is 192 samples), so this will, unless you have a player/testing tool that sample-aligns the valid starting point of the stream, or one that decodes the entire stream prior to playback, you will experience slight, and correlated differences in starting point when you seek to a particular section within a track.

It does not yield different sounding results. The bitstream sent to a mixer and later D/A converter will be identical, but you will be starting playback at a slightly different stage.

This, of course, renders the entire Zeilig paper utterly invalid. (And this is also, if you want to do ABX testing, you should always pre-decode your testing candidates to the same, preferably uncompressed format, and ensure that your testing candidates are sample aligned.

This is also why you'd at least want someone with a basic understanding of computer science, programming or how computers work involved in the design of a test, instead of leaving it to an oncologist.

That's not quite right. FLAC being lossless means that you can't turn down the bitrate and screw it up. It should always be able to recreate the WAV file.

Here is a good FAQ for anyone interested: https://xiph.org/flac/faq.html#general__lowest_bitrate

Ah for FLAC?

• You need to go to the flac website and download it.
  
• copy the folder (not the archive) into your foobar install folder.
  
• Go to convert, point it at FLAC.exe

You can do this for a number of other formats, LAME for MP3s as an example.

Why are you using iTunes anyway? On windows it's pretty shithouse. You can manage iPod music with Foobar and it plays everything without eating all your RAM and CPU.

I should've been clearer: you will also need a FLAC decoder of course. Just get the reference encoder/decoder from xiph - it has good documentation
you feed the resulting wav files to LAME. By using the encoders/decoders directly, you will need to read a bit of documentation which can learn you very useful things

Does for me: https://i.imgur.com/CzhntL3.png

So maybe some dependency missing needed to extract meta data from flac files? A short search on my systems shows I have media-libs/flac (https://xiph.org/flac/) installed..that's the only direct flac package I can find. kfilemetadata is compiled with ffmpeg and taglib support...no clue how this is on other distros, maybe there is some kfilematadata subpackage needed...

Edit.: Damn, sorry, german screenshot: "Dauer" == "Duration" ;)

On a very technical side, does anyone know if there's some caveat to FLAC's decorrelation channel assignment as shown here? If I make a very simple FLAC file of a single frame in normal stereo mode (0x1) containing just samples of 0, it checks out when running flac -t stereo_file.flac. However, if I change the single byte 0x18 to 0x88 in the frame header, to signify left and side channels, and change nothing else in the file, the same command yields Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC (technically it first also gives the bad CRC error code if I do not fix that, also, but even after fixing both the header and footer CRCs, I still get the above error code). I do not know what is causing it.

The entire left-side erroneous file looks like:

>00000000: 664c 6143 8000 0022 2000 2000 0000 0000

00000010: 0000 0ac4 42f0 0000 0000 bb7d f04e 1b0a

00000020: 2570 6575 27a7 e108 ae23 fff8 d988 0081

00000030: 0000 0000 0000 a880

While the equivalent, left-right, acceptable file is:

>00000000: 664c 6143 8000 0022 2000 2000 0000 0000

00000010: 0000 0ac4 42f0 0000 0000 bb7d f04e 1b0a

00000020: 2570 6575 27a7 e108 ae23 fff8 d918 0060

00000030: 0000 0000 0000 119a

Only the byte at 0x002D(0x88 vs 0x18), and the CRCs at 0x002F(CRC8) and 0x0036(CRC16) differ between these two files.

The thing is, I don't have to. You can just take a look at freely available documentation and calculate the CD quality FLAC files' maximum bitrate; the number is 1411.2 Kbps. CD quality is the most available quality by a wide margin as you can imagine, that's what "usual" is. And YouTube recommends 8000 Kbps bitrate for 1080p videos.

The FLAC spec is both a codec and a lightweight container, but the container is so tightly specified it's generally considered to only be able to contain FLAC-encoded streams.

Of course there are some players that are able to decode oddball combinations, but I would never recommend it.

Although I am frustrated that FLAC officially supports embedded cue sheet but player support is pretty lacking.

Have you tried passing --verify with the standard command line flac tool? That might be all you need, though I'm not sure if it stores the checksum in the file. Might be worth testing. Link to read more.

> However, the smaller you compress your FLAC when you initially save it, the more math your player’s processor has to run on it in memory to uncompress it before it can be played.

Small correction: with FLAC, the compression level pretty much only affects the encoding speed. See this graph. Minimum compression only decodes ~8% faster than maximum.

Then why do you think flac files' bitrates are all over the place? (What you see in your media player is also only the average bitrate, since it varies at any given moment and also depends on the flac compression level) You don't even specify bitrate with flac. It's always variable. By definition. It is not constant.

"You cannot control the bitrate much and the result can be from around 100% of the input rate (if you are encoding noise), down to almost 0 (encoding silence)." (xiph.org

"variable rate encoding is inherent in lossless compression schemes such as FLAC" (Wikipedia)

Fabio, there's no audible difference between a wav and a flac, and I'll explain why.

If you've ever zipped a file, you know that it gets smaller when it's zipped, and then when you unzip it, it's back to its normal size, with no data loss. The way this is achieved is through using math to perfectly represent a string of information, instead of simply storing that entire string.

Flac accomplishes the same thing with waveforms.

The trade-off is that to recreate the waveform in the case of the flac file, the computer must do some calculations to make the shorthand equation that perfectly describes the shape of the waveform back into the waveform. This happens well in advance of the waveform being converted from digital to analog.

In the case of the WAV file, the same string of 0s and 1s that represent the wave form is fed into the DAC, simply without the extra step of calculation.

Now I'm not saying that 2QWEST didn't hear a difference switching from FLAC to WAV as he asserts. He may well have - it could have been that his ears were less fatigued, he was in a better mood, or perhaps when he played the WAV file, his computer played it with a different audio program that applied some EQ - or one of many other possible explanations for why his perception is that WAV sounds better than FLAC.

But I can tell you, there's no difference in the 1s and 0s that come out of a FLAC v.s. a WAV, so it's got to be something other than the file format. Hope you find that illuminating.

edit: in case my points are still not convincing, you can read more here: https://xiph.org/flac/faq.html#tools__wave_flac_wave

The FLAC reference encoder options are explained at https://xiph.org/flac/documentation_tools_flac.html

-8 -e -p are for maximum compression, and this is extremely slow, but good if you really need to conserve disk space & bandwidth (to the point where a ~1% difference matters to you).

-V tests to make sure the output is correct. IMHO not necessary unless debugging the encoder.

-T FIELD=VALUE is adding metadata (tags).

I would honestly just use the original FLAC tools. You can make it generate replay gain side data like this:

flac -8 --verify --no-padding --replay-gain -e -f *.flac

(This will reencode all FLAC files in the current directory and add replay gain side data. Make sure to isolate every album in its own folder because FLAC will calculate both Album- and Track-replay-gain data)

Here’s the FLAC change log: https://xiph.org/flac/changelog.html

I see some bug fixes in very early release versions, mostly around using the tool to encode files.

I only saw one bug that seems like it could compromise audio quality in the output file, fixed in the 1.0.1 release:

> Fixed a serious bug with flac and raw input where the encoder was trying to rewind when it shouldn't, which would add 12 junk samples to the encoded file. This was not present in WAVE encoding.

Most of the releases seem to be addding features and options.

Command-line option, so not one click.. but some may prefer:

First, download flac: https://xiph.org/flac/download.html. Then, on Linux/Macos, to decode all flac -d /path/to/your/music/*.flac. On Windows, navigate to the folder where your music is in cmd.exe, then: FOR %f IN (*.flac) DO "C:\folder\where\flac\installed" -d "%f"

Flac has a official program, called flac

If they all have the standard .flac file extension and are all in a single directory try the command >flac -st -- *.flac 2> ~/badflacs.txt that should create a text file in your home folder with a list of errors encountered.

or you could use http://flacfrontend.sourceforge.net/ if you have flac installed

Think you are going about this wrong. You're thinking about the downloading aspect but what you really want to know is where in a flac binary file there is corruption regardless of the download method..

That part is off topic for this sub, you may want to try a different sub. But just FYI flac files do have their own error handling per https://xiph.org/flac/features.html

> Each frame contains a 16-bit CRC of the frame data for detecting transmission errors. The integrity of the audio data is further insured by storing an MD5 signature of the original unencoded audio data in the file header, which can be compared against later during decoding or testing.

> Because of FLAC's framing, stream errors limit the damage to the frame in which the error occurred, typically a small fraction of a second worth of data.

The flac command line tools do give you options to test (-t) and analyse (-a) so really what you need to learn is how to work with the data those tools give you. I'm not enough of an audiophile to give you specific step-by-step on that but there should be other audiophile/audio codec type subs around you can try in.

EDIT: Like /u/Boku-no_Pico mentioned most media players know how to work with the media file's own error handling & will automatically try to skip over corrupt parts so as to finish playback of the file. But I suppose that doesn't really help you since you'd rather a file playback fail completely on playback rather than error correct itself. But maybe someone in /r/VLC can suggest an alternative method to force playback to fail on error.

The flac files might be in a format the the build-in decoder does not manage to play, might be a device bug. The ExoPlayer uses the native libFLAC library (https://xiph.org/flac/) which should play flac files in a correct way.

" The integrity of the audio data is further insured by storing an MD5 signature of the original unencoded audio data in the file header, which can be compared against later during decoding or testing. "

https://xiph.org/flac/features.html

Usually we try to avoid sending big FLAC files, but in this case it might be necessary.

First, can you check that they are not corrupted? This can be done using the flac -t file.flac command line, see the docs.

In general try to provide at least the following info:

• Relevant portions of airsonic.log
• Browser console, if possible (accessible with Right-click, Inspect element on the page)

I'm not sure what order those values are, but you could check individually with --show-tag=NAME for example --show-tag=REPLAYGAIN_ALBUM_GAIN

Actually I see metaflac can set them automatically with --add-replay-gain. So you could use that. You'd want to pass all the files in the same command so it calculates the album gain correctly.

I'm using this page https://xiph.org/flac/documentation_tools_metaflac.html as reference.

flac is compressed, but can be decompressed, bit for bit back to wav.

you'll get no audible degradation with flac compared to wav, but you'll 1/2 the file size (depending).

there's no reason to save wav in modern digital listening.

https://xiph.org/flac/

here's a great, free tool for this sort of thing -- http://tlh.easytree.org/

If you want to convert flac to be readable by iTunes, you can just download offical flac and decode the files into .wav. They will become even larger than the flac files, but will be literally identical in terms of the resulting pcm stream when played back. You can then compress into apple lossless to reduce size back to similar to flac if you care to. Nothing is lost in these conversions. You could do it a thousand times and your track is still perfect.

This provides a good explanation on what FLAC is. FLAC was created several years after the MP3 file format (MP3 in 1993 and FLAC at the end of 2000), I'm surprised there are people who use reddit that still don't know about it.

FLAC - Free Lossless Audio Codec - Xiph.org

https://xiph.org/flac/FLAC stands for Free Lossless Audio Codec, an audio format similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality.

It might seem paradoxical, but sometimes/often it's the case that with greater levels of compression, encoding requires extra CPU but decoding doesn't.

One major reason for this is that compression is a process of finding a way to model the data so that it can be represented more compactly. So compression is a process of searching for patterns and structure in the data that can be exploited, then restructuring the data to exploit those patterns. When decompressing, you already know what decisions were made to model the data, so you mostly just have to undo the restructuring by basically following instructions.

For example, if you look at the official FLAC software documentation, you will see that one of the differences between compression levels 4 and 5 is that 4 uses the -M flag whereas 5 uses the -m flag. Both are forms of mid-side encoding, but with -M the encoder makes an educated guess and goes with it whether it's right or wrong, whereas -m encodes both ways every time and then throws away the results of the computation that didn't work as well and only saves the other. (In other words, -m seeks out the best encoding approach by trial and error.) So it gives slightly smaller files (certainly no larger), it creates a lot of extra work during compression, and it creates no extra work at all during decompression.

Of course, this is only a general rule. There are definitely cases where a compression technique can require more processing during both encoding and decoding. It's some of both.

TLDR: You may not actually be saving much battery life.

Thank you so much for this! Lossless vinyl/tape rips are a real treat.

P.S. if you want to lower the file size of the rip without sacrificing quality you can convert WAV to FLAC.

FLAC only supports up to 8 channels per stream (format specification here), so you can't have 64 channels in a bare .flac file (unless I've missed something). You can, however, put multiple FLAC streams in a container like Ogg or Matroska to get more than 8 channels (source).

it's hard to say,

flac is a lossless way of compressing an audio file.

wildly simplified, they convert a stereo audio stream it into a mid-side stream, and losslessly encodes the difference.

https://xiph.org/flac/documentation_format_overview.html

you mentioned you're going to opus, which dynamically varies bitrate to accomadate filesize

Rip them as wav files. Compress them to flac.

I use EAC and the official FLAC encoder. You can setup EAC to do the rip and conversion all with one press of a button.

OGG can be compressed with vorbis, or uncompressed with flac. The quality and file size changes quite a bit between vorbis mode or flac. That's why for PVs I just use aac because it beats vorbis quality while still being compressed.

And yeah flac is not a native format for phones, even though porting flac support would probably be easy to do on Android. https://xiph.org/flac/download.html

We're not really disagreeing - but you seem to be conflating the implementations with the specification - the specification, command-line tools and library have three different licenses, https://xiph.org/flac/license.html

If you're looking to do a FLAC rip, the FLAC website has a few decent tools.

A good general purpose audio ripping / transcoding suite of utilities is dBpoweramp

Almost none of what you've just said is true. FLAC can actually be decoded more quickly than ALAC by any modern device. Whatever stupid proprietary processor Apple was using in the iPod Classic in 2004 might've been able to decode ALAC faster, but that's completely irrelevant these days.

You've also neglected to mention that ALAC wasn't open source for many years after its release. From 2004 until 2011, it was completely proprietary, and Apple only open-sourced it when they realized they weren't going to kill FLAC.

> You'll enjoy an improvement by doing so because CD is PCM, which is literally an uncompressed form of FLAC.

So digital audio players and FLAC decoders normally skip the FLAC decompression to uncompressed PCM data step? How in your mind does the FLAC decoding and playback process go?

I know you're not a software engineer but you are

> reasonably well-informed and have function eyesight

therefore you should have no trouble understanding this FLAC API - https://xiph.org/flac/api/group__flac__stream__decoder.html

All FLAC conversions use... the FLAC converter. One cannot perform a haphazard job at using that software. Moreover, signal degradation is not possible in a lossless format. Not sure what you are trying to say here.

Directly from the FLAC website, documentation, modeling section: "MODELING

In the next stage, the encoder tries to approximate the signal with a function in such a way that when the approximation is subracted, the result (called the residual, residue, or error) requires fewer bits-per-sample to encode. The function's parameters also have to be transmitted so they should not be so complex as to eat up the savings. FLAC has two methods of forming approximations: 1) fitting a simple polynomial to the signal; and 2) general linear predictive coding (LPC). I will not go into the details here, only some generalities that involve the encoding options.

First, fixed polynomial prediction (specified with -l 0) is much faster, but less accurate than LPC. The higher the maximum LPC order, the slower, but more accurate, the model will be. However, there are diminishing returns with increasing orders. Also, at some point (usually around order 9) the part of the encoder that guesses what is the best order to use will start to get it wrong and the compression will actually decrease slightly; at that point you will have to you will have to use the exhaustive search option -e to overcome this, which is significantly slower."

Notice that there are in fact options which can increase and decrease the accuracy vs. speed of the waveform modeling.

FLAC stands for Free Lossless Audio Codec. Basically it's a way to encode and decode music much like MP3 is a way to encode music. If you don't have it you can download it here.

Could you elaborate on why you want to downsample?

If you are just trying to save disk space, give flac a try. It is a lossless compression tool for audio. I usually get around 50% compression on CD-quality (44/16) audio.

As for re-samplers, I have little experience. As others have mentioned, I know SoX has a lot of options.

Personally, I am playing with upsampling: I am doing a 4x upsample of CD audio. Note I am changing the sample rate only, not the bit-depth. (Going from 44.1khz to 176.4khz.) I found that my DAC (Emotiva Stealth DC-1) was a bit fatiguing at 44/16, but the upsampled files don't seem to have this affect. I don't perceive any difference in audio quality though. That is, I don't think I could tell the difference between 44/16 and 176/16 in a blind test. But I've been that this for a couple months now, and definitely have virtually no fatigue since I started doing this.

I am using libsamplerate (aka "Secret Rabbit Code") for my upsampling. I believe it can also downsample. I wrote a simple script to do batch processing.

Interesting observation: my original CD source files are in flac format. I have to restore them to wav before I run the SRC. I do a 4x upsampling, then re-compress in flac. The wav files grow in size by 4x, but the difference in FLAC file size is only 2x. This suggests to me that libsamplerate is probably putting in a lot of duplicate information. (E.g., I might get the same result with 2x upsampling, but haven't had time to experiment.)

I'm not familiar with the format, so I couldn't make one for Windows or Linux either. Luckily for me, I don't have to because there's a while bunch of tools that already support it.

A lossless format would reduce the amount of space the game takes up, but it wouldn't offer the speed boost to low-end systems (because it would still need to be decoded). Also, a lossless format would still take up a fair amount of space, the compression rate is only about 53-63% among all lossless formats, so the 38 gigs of Titanfall audio would still be over 20 gigs at best. A good quality codec in 320 would reduce this further and would provide identical sound (or almost identical if you have super ultra fancy headphones/speakers and trained ears).

I do think audio quality should be increased, though, and I do think we'll see more of an increase in audio quality in games now that we're not limited by the 360's DVD size limitations (like it or not, console limitations affect PC, especially in something that a lot of people don't care a lot about like audio).

DTS sponsored an interesting study where they measured the brain response of 100 individuals while watching video content with audio and compared the increase in pleasure response when increasing video resolution vs processing audio to be more pleasurable. Higher video resolution made very little difference, while a change in audio significantly increased measured pleasure. While the study doesn't deal with higher quality speakers/headphones or bitrate, the results are still very interesting.

Having uncompressed specifically is hard to justify. In theory it can save you CPU usage, but in practice:

• Audio decoding is very light compared to all the other CPU-bound tasks in a game.
• Consoles are usually way more GPU bound than CPU bound anyway. Far Cry 3, for instance, deliberate offloads some lightning book-keeping to the CPU to free GPU cycles (GDC paper)
• Streaming audio can work well for music, but not that much for anything else. You can't do 'audio popup' like you do with textures since there is no pre-existing geometry to fill in temporarily. You'd get completely off-sync ambient sounds or voice, which is unacceptable. You end up needing some form of memory preloading, and that's an area where last-gen consoles struggle quite a lot. Decoding once to memory, or even paying the decoding price multiple times and saving 80%+ in RAM usage would be preferable to enormous disk I/O price of loading uncompressed audio.
• FLAC is actually really fast. It's integer only, which is great considering games saturate CPU FP units quite a lot, and deliberately designed for fast decoding. I don't think any game can even afford being so CPU saturated that FLAC decoding breaks the budget: it'd be in a very risky situation already, since pretty much any background activity would be enough to screw everything up.