EAC : size difference with different FLAC encoders

[sirt]

Hi,

Actually, today I re-ripped an album I ripped in the past with an old FLAC (2007). This time, I used latest FLAC (2017). See below a MediaInfo log comparison for same track ripped being based on exact physical album (mine) - I highlighted in bold Bit rate, Stream size & Writing library.

As you can see track processed with latest FLAC is slightly smaller and bitrate is also lower. Isn't that a problem ? Actually, I tried with several albums and it seems to be systematic : less size, lower bitrate. So it sounds 'lower' quality to me as I am uisng exactly the same source. I also retried with FLAC (2007) and I obtained exact bitrate and size than the first CODE, so the 'changes' are clearly related to FLAC (2017).

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 4 min 0 s
Bit rate mode : Variable
Bit rate : 976 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Bit depth : 16 bits
Stream size : 28.0 MiB (100%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 4 min 0 s
Bit rate mode : Variable
Bit rate : 971 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Bit depth : 16 bits
Stream size : 27.9 MiB (100%)
Writing library : libFLAC 1.3.2 (UTC 2017-01-01)

[sneaker_ger]

Lossless compression doesn't have to always result in identical bitrate to be lossless. Why don't you decompress to PCM and compare the checksums? They should be exactly identical (unless there was a reading problem, Audio CDs don't have much error resilience).

[sirt]

Could you tell me how I could do such a thing e.g. decompress then compare checksums ? Actually I copied both flac to a folder and flac.exe (2017 version) then I used a bat file with following command :


flac -d track.flac


Is that what you intended me to do ? I'm not sure whether it is correct as I used FLAC '2017' build to decompress both flac tracks. And I also don't have checksums.

Buth uncompressed WAV files obtained have same size.

[LoRd_MuldeR]

flac --stdout --force-raw-format -d input.flac | sha1sum

You can replace "sha1sum" with "cksum", "md5sum", "sha256sum" or whatever hash algorithm you prefer. Be aware, though, that a cryptographic hash gives completely different output, even if only a single bit of the input differs.

[sneaker_ger]

Or:
ffmpeg -v 0 -i "track.flac" -f crc -

[sirt]

flac --stdout --force-raw-format -d input.flac | sha1sum

You can replace "sha1sum" with "cksum", "md5sum", "sha256sum" or whatever hash algorithm you prefer. Be aware, though, that a cryptographic hash gives completely different output, even if only a single bit of the input differs.

Thanks LoRd_MuldeR but actually it doesn't seem to work like that. I deleted '| sha1sum' and then re-tried my bat file. This time a value for --endian and --sign parameter is requiered but I have not clue what to use. Moreover, how to add checksum ?


sneaker_ger, then I downloaded ffmpeg and tried what you suggested and I get a result :

CRC=0xe14afe84

Same for both flac. Is that what I am supposed to check ?

[sneaker_ger]

Yes.

sha1sum.exe and the like aren't included in Windows, I believe. LoRd_MuldeR probably always has git or something like that installed that comes with those tools...

[LoRd_MuldeR]

Thanks LoRd_MuldeR but actually it doesn't seem to work like that. I deleted '| sha1sum' and then re-tried my bat file. This time a value for --endian and --sign parameter is requiered but I have not clue what to use. Moreover, how to add checksum ?

You are right. When using "--force-raw-format" you need to specify "--endian" and "--sign" as well. I forgot about that :scared:

So try, for example, like this:
flac --stdout --force-raw-format --endian little --sign signed -d input.flac | sha1sum -d input.flac | sha1sum

(Actually it doesn't matter which "endianess" you select, or whether you use signed or unsigned. It just needs to be the same for both files that you want to compare)


sha1sum.exe and the like aren't included in Windows, I believe. LoRd_MuldeR probably always has git or something like that installed that comes with those tools...

It doesn't come with Windows, yes. It's included in MSYS(2) though, which is part of Git for Windows. But there is a standalone download of Gnu Core Utils here:
https://sourceforge.net/projects/gnuwin32/files/coreutils/5.3.0/coreutils-5.3.0.exe/download

[sirt]

Ok it seems to work :



da39a3ee5e6b4b0d3255bfef95601890afd80709 *-
17.flac: done

da39a3ee5e6b4b0d3255bfef95601890afd80709 *-
07.flac: done


So, once again, there seem to be similar checksum.

[mariush]

It's just slightly different compression. Somewhat normal, since they're two different versions.

You can launch flac from command line and see :

To encode:
flac [-#] [INPUTFILE [...]]
-# is -0 (fastest compression) to -8 (highest compression); -5 is the default

So you can encode your audio track once with -0 and once with -8 and they'll have different sizes, but when decoded by a player, or if you decode it back to wav, the output will be identical.
It's like compressing your wave file with winzip, winrar or 7zip with different compression settings. You're trading speed for more compression and maybe a very tiny more decoding complexity.

If you want, you can do even better than the reference flac by using FlacCL from CueTools which can also speed up encoding by using video cards (OpenCL) to do some calculations

FlacCL goes even a step further by adding higher compression numbers, from -0 to -11 where the higher compression is achieved by compressing variable length audio segments instead of fixed length segments like the reference encoder does.
Any reference decoder or quality decoder can play these audio files without any problems.
Here's a comparison with Tyco - Dive ( 2011) , A walk (track 1)

38.832.295 bytes 879 kbps reference libFLAC 1.2.1 20070917
34.772.560 bytes 878 kbps reference libFLAC 1.3.1 20141125 (foobar2000)
34.768.149 bytes 878 kbps CUETools FLACCL 2.1.5 (without metadata like artist, track title)


d:\Programs\EncodingTools\flac\opencl\CUETools_2.1.5>CUETools.FLACCL.cmd.exe --lax -11 --opencl-type GPU -o y:\temp\test\cue.flac "y:\temp\test\a walk.wav"
CUETools FLACCL 2.1.5, Copyright (C) 2010-2013 Grigory Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename : y:\temp\test\a walk.wav
File Info : 44100kHz; 2 channel; 16 bit; 00:05:16.9200000
Device : Ellesmere, Platform: "AMD Accelerated Parallel Processing", Version: OpenCL 2.0 AMD-APP (2236.10), Driver: 2236.10
Results : 483.08x; 34768149 bytes in 00:00:00.6560375 seconds;


and another example, a 24 bit 96000 Hz track (Future Sound of London , Papua New Guinea Andrew Weatherall Mix)

232.229.092 bytes reference libFLAC 1.2.1 20070917
231.355.011 reference libFLAC 1.3.1 20141125 (foobar) (32x encoding speed from flac to flac)
227.354.660 cuetools -11 as above (~215x encoding speed from wav to flac)
227.651.487 cuetools -8 (~216.15 encoding speed, wav to flac, -8 is like reference encoder, most compatible with everything)

d:\Programs\EncodingTools\flac\opencl\CUETools_2.1.5>CUETools.FLACCL.cmd.exe --lax -11 -o y:\temp\test\2.flac "y:\temp\test\Papua New Guinea (Andrew Weatherall
Mix).wav"
CUETools FLACCL 2.1.5, Copyright (C) 2010-2013 Grigory Chudov.
This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
the extent permitted by law. <http://www.gnu.org/licenses/> for details.
Filename : y:\temp\test\Papua New Guinea (Andrew Weatherall Mix).wav
File Info : 96000kHz; 2 channel; 24 bit; 00:11:26.1120000
Device : Ellesmere, Platform: "AMD Accelerated Parallel Processing", Version: OpenCL 2.0 AMD-APP (2236.10), Driver: 2236.10
Results : 214.94x; 227354660 bytes in 00:00:03.1921826 seconds;

[sirt]

Thanks mariush, it is an interesting statement. Then you 'gain' some MB per track with your solution. Actually, I want to use EAC as it is (from what I know) the only solution solution to perform 'perfect rips' e.g. create all the stuff (.cue, .m3u...), test and copy tracks accurately, check retail CD copy with database ect. It can also detect and correct errors which would avoid artefacts and anything nasty related. I am not sure your way via CueTools offer such steps. Otherwise, perhaps there is a way to download CueTools FLAC build and sue it as a compressor in EAC ?

[hello_hello]

Thanks mariush, it is an interesting statement. Then you 'gain' some MB per track with your solution. Actually, I want to use EAC as it is (from what I know) the only solution solution to perform 'perfect rips' e.g. create all the stuff (.cue, .m3u...), test and copy tracks accurately, check retail CD copy with database ect.

There's no doubt several ripping programs and/or audio players that'll do all that. Probably not with EAC's brain melting range of settings, but ripping securely, chatting to the AccurateRip data base, converting, tagging, creating cue sheets etc.
I think AccurateRip began life as a dBPoweramp add-on. As far as I know EAC and dBPoweramp are the only two programs that can submit CD info to the database, but other programs can retrieve it.

CUETools should do all the important stuff that EAC does, but I don't use it much myself as I rip with foobar2000. You can download a zip file containing the CUETools encoders from here. https://hydrogenaud.io/index.php/topic,106446.msg872600.html#msg872600
The most recent encoders are currently attached to the last post in the thread.

On the flac file size thing.... you could also re-encode your two flac files as flac files again, but this time using the same version of the encoder, and the file sizes and checksums should match. In fact the checksums should match already if the audio being compressed was the same. Some lossless encoders automatically calculate checksums. The reference FLAC is one of them. WavPack is another. I hadn't looked until now but I thought that would be something MediaInfo might display. Apparently not. You can configure foobar2000 to display it though.

https://s28.postimg.org/4p5mdn9kt/foobar2000.gif

Edit: I should clarify.... The MD5 is calculated for the audio being encoded, so if you encode the same audio as FLAC twice, using different compression levels and adding different tags each time, the calculated MD5 will still match even if the file sizes are very different. The same should apply even when you compress with a different codec. WavPack this time, same MD5.

https://s27.postimg.org/k6zk0lglv/Wav_Pack.gif

If you use a GUI for converting and it has a dithering option, make sure it's not active or it's disabled otherwise the MD5's will never match.

[Ghitulescu]

I am not sure what you try to achieve or complain.
FLAC is in a sort of speaking a sort of ZIP, but in the end the original file is restored 100% with no errors. Surely, a single bit in a defective archive will render the whole file maybe useless, therefore some archivers like RAR have developed several algorithms to verify and to reconstruct back the damaged data.

[tebasuna51]

...
Is that what you intended me to do ? I'm not sure whether it is correct as I used FLAC '2017' build to decompress both flac tracks. And I also don't have checksums.

Buth uncompressed WAV files obtained have same size.

To see if two files are bit-identical you don't need any extra soft. You can use the old MS-DOS command File Compare (FC) in binary mode (/B):

FC /B 1.wav 2.wav

[Groucho2004]

I simply use the --verify switch with flac:
-V, --verify Verify a correct encoding by decoding the
output in parallel and comparing to the
original

This way I know that the decoded file will be the same as the original (unless there is something wrong with the memory, hard drive, etc.).