Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC v1.3.3 (Read 159038 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: FLAC v1.3.3

Reply #125 –
Here I go reading and answering the question, without noticing that the front-end was mentioned.

@gilibaus , beware the front-end; I had it eating my files: post 116 up here, or https://hydrogenaud.io/index.php?topic=99803.msg921798#msg921798
I don't know what it does wrong, but I never had the CLI do this. Does the front-end rename even incompletely converted temp files to overwrite the original?

Rather, use e.g. foobar2000,, bitcompare to the original and only then delete.

Re: FLAC v1.3.3

Reply #127 –
I’m curious what happened to 1.3.4... it seems we went backwards to 1.3.3 again?
 

Re: FLAC v1.3.3

Reply #128 –
Following.  Doing some CD rips and want to make sure I'm staying up to date with these things. Currently using the 1.3.2 that ships with EAC.

Re: FLAC v1.3.3

Reply #133 –
FLAC 1.3.3 + LibFLAC_dynamic.dll  (x86 & x64)
MSVC 2019 (v142) SDK version 10.0.19041.0
commit 313ab58
 (2021-07-11)

Re: FLAC v1.3.3

Reply #134 –
Any advice on how to build flac statically in msys/mingw?
My commands:
Code: [Select]
#!/bin/bash
export CC=clang CXX=clang++
git clone https://github.com/xiph/flac.git --recursive
cd flac
cmake -B build -G Ninja -S ./ \
    -DCMAKE_BUILD_TYPE=Release \
    -DWITH_OGG=OFF \
    -DBUILD_EXAMPLES=OFF \
    -DBUILD_DOCS=OFF \
    -DINSTALL_MANPAGES=OFF \
    -DCMAKE_EXE_LINKER_FLAGS='-fstack-protector-strong -static'
ninja -C build
“We are not stuff that abides, but patterns that perpetuate themselves.” – Norbert Wiener

Re: FLAC v1.3.3

Reply #136 –
@john33  i noticed a small increase in compression after installing your compile for FLAC 1.3.3 over my previous vanilla 1.3.2 install. Is that just the regular difference between the two versions or did you tweak anything, do you have an update log available somewhere?
The difference is very minor, about 5000 bytes in 239 files, but still.

Re: FLAC v1.3.3

Reply #137 –
Quote from: Sundr0wn on
@john33  i noticed a small increase in compression after installing your compile for FLAC 1.3.3 over my previous vanilla 1.3.2 install. Is that just the regular difference between the two versions or did you tweak anything, do you have an update log available somewhere?
The difference is very minor, about 5000 bytes in 239 files, but still.
Hmmm, interesting, but not of my doing. It is perhaps possibly down to the Intel compiler although I tend to doubt it. Much more likely to be some change in the library.

Re: FLAC v1.3.3

Reply #139 –
Spoiler (click to show/hide)

I'm curious about the file size differences I see vs. 1.3.2 and also when comparing john33's build with either Griever's or Ozz's. Also curious why john33 rolled back to the commit he did. I probably should've tried to match the three builds by commit but I could only find ce6dd6b on rarewares and 7a35c528 looks like the last one Griever posted...can the compiler used actually make a difference in the output file size? To be clear, this has nothing to do with the "bloat" bug mentioned in this topic.

Griever's is fastest on my old machine by a decent enough amount for hi-res files that I'll probably stick with it. I saw it hit the mid 70x range in fb2k while the other two were high 60s, very scientific! john33's build seems to make 96/24 files that are ~3 KB larger than the other two for whatever reason. Sometimes the 1.3.3 builds are collectively larger than 1.3.2 for 96/24, and sometimes they're smaller. All three builds are faster than 1.3.2. I tested using the same rip of the same track from that post I made here 14 years ago, I also tried the 2015 96/24 release, and another Hi-Res track. Obviously can't[1]share any of the copyrighted test files themselves.

There was only a <1 KB difference between any of the builds or 1.3.2 for 44/16, using Muse's "Take a Bow" from that old post. Entirely inconsequential unless I'm right at the boundary between requiring an extra NTFS cluster. Oh no...31.3 MB (32,821,248 bytes) "on disk" for all of the above in any case, so it's not going to be noticeable. No, I am not going to check my library for FLAC files that are "some multiple of 4 KB minus <1 KB" in size, and I'm pretty sure the drive on my NAS with most of the music on it has 64KB blocks either way, so even the 96/24 differences aren't really differences. Somewhat comically, at least for these three files, the 1.3.2 files as a whole win...

Test File // VersionGriever 7a35c528Ozz 313ab58john33 ce6dd6b1.3.2
01. Take a Bow.flac 96/24107 MB (112 904 836 bytes)107 MB (112 904 853 bytes)107 MB (112 907 505 bytes)107 MB (112 910 775 bytes)
01 Take A Bow.flac 44/16 CD31.2 MB (32 819 379 bytes)31.2 MB (32 819 370 bytes)31.2 MB (32 819 357 bytes)31.2 MB (32 819 331 bytes)
01. One Last Kiss 96/2483.5 MB (87 594 621 bytes)83.5 MB (87 594 348 bytes)83.5 MB (87 597 426 bytes)83.5 MB (87 581 227 bytes)
Total222.5 MB (233 318 836 bytes)222.5 MB (233 318 571 bytes)222.5 MB (233 324 288 bytes)222.5 MB (233 311 333 bytes)
Diff+7,503 bytes+7,238 bytes+12,955 bytes0
Build Namemingw-w64-x86_64-flac-git-1.3.3.r3909.7a35c528FLAC_1.3.3_313ab58-Ozzflac-v1.3.3.git-ce6dd6b-x64flac-1.3.2-win
realized this explorer screenshot was pointless after checking the exact file sizes and adding them as a table courtesy of a very convenient BBCode table generator[2]
Spoiler (click to show/hide)
The only time I re-encode anything these days anyways is when certain Hi-Res download sites give you bizarre, larger than PCM padded? 4616 kbps 96/24 FLAC files for whatever reason. I don't think this is the bloat bug either, the entire album was like this, as if it was just PCM with ogg headers. "Bigger is better." Those get beat with the Level 8 stick out of spite. Apologies for not comparing all of them more, editing the hardlink to flac.exe is a pain in the butt.

Beautiful World [1.3.1 - Source]180 MB (189 548 998 bytes)
Beautiful World [PCM[3]]175 MB (183 586 602 bytes)
Beautiful World [1.3.2 Level 8]116 MB (122 368 039 bytes)
Beautiful World [Griever Level 8]116 MB (122 369 621 bytes)
Beautiful World [Griever Level 0]132 MB (138 737 844 bytes)
Thank you to all three of you for compiling these BTW!
1 publicly↵
3 still tagged with album art and everything too...↵

Re: FLAC v1.3.3

Reply #140 –
Quote from: sheik124 on
There was only a <1 KB difference between any of the builds or 1.3.2 for 44/16, using Muse's "Take a Bow" from that old post.

Just to be sure that it isn't padding or seektable ... tried
metaflac.exe --dont-use-padding --remove-all
?
(It will also remove the vendor (version) string, so make a copy first.)

Quote from: sheik124 on
Those get beat with the Level 8 stick out of spite.

I use -8 pretty much always, so I have to resort to -e as spite switch.

Re: FLAC v1.3.3

Reply #141 –
Quote from: Porcus on
Quote from: sheik124 on
There was only a <1 KB difference between any of the builds or 1.3.2 for 44/16, using Muse's "Take a Bow" from that old post.

Just to be sure that it isn't padding or seektable ... tried
metaflac.exe --dont-use-padding --remove-all
?
(It will also remove the vendor (version) string, so make a copy first.)

You know, I don't think I've ever used metaflac or even flac.exe itself, it's usually piped through via foobar or EAC or something.
If you ever want a lazy way to do operations like that for all FLAC files in a folder + its subfolders,
Code: [Select]
FOR /F "tokens=*" %G IN ('dir /b /s *.flac') DO metaflac.exe --dont-use-padding --remove-all "%G"
No fancy table this time
Code: [Select]
Before:
2021-09-18  01:04 PM        32,819,331 01 Take A Bow 1.3.2.flac
2021-09-18  01:09 PM        32,819,357 01 Take A Bow flac-v1.3.3.git-ce6dd6b-x64.flac
2021-09-18  01:07 PM        32,819,370 01 Take A Bow 1.3.3_313ab58-Ozz.flac
2021-09-18  01:10 PM        32,819,379 01 Take A Bow mingw-w64-x86_64-flac-git-1.3.3.r3909.7a35c528.flac
After:
2021-09-18  11:46 PM        32,689,426 01 Take A Bow 1.3.2.flac
2021-09-18  11:46 PM        32,689,452 01 Take A Bow flac-v1.3.3.git-ce6dd6b-x64.flac
2021-09-18  11:46 PM        32,689,474 01 Take A Bow mingw-w64-x86_64-flac-git-1.3.3.r3909.7a35c528.flac
2021-09-18  11:46 PM        32,689,476 01 Take A Bow 1.3.3_313ab58-Ozz.flac
The "giant" 4616 kbps FLAC out of curiosity:
2019-10-22  06:18 PM       189,548,998 01 - Beautiful World.flac - Before
2021-09-18  11:53 PM       183,454,510 01 - Beautiful World.flac - After
2021-09-18  03:09 PM       183,586,602 01 - Beautiful World.wav - Still tagged with embedded album art too BTW...
2021-09-18  03:05 PM           446,533 heart station.jpg

Re: FLAC v1.3.3

Reply #142 –
for /r %G IN (*.flac) works as well I think. So the differences stayed about the same, and that is not the explanation. (Reason why I asked is this thread.)

But the Beautiful World must have had a 5.5 gigabytes padding or something? Given that the art was that 446553 file. (You can find art size by Mp3tag.)
dBpoweramp has the option to encode to "uncompressed" FLAC (I don't remember how, does maybe it forces VERBATIM for everything ... everything but wasted bits I think). Probably it was implemented to attract audiophools or maybe to shut them up.
It is possible to get out that information by checking the output of flac -a - which would be a text file same order of magnitude as the file or something, that is for the curious.

Re: FLAC v1.3.3

Reply #143 –
"uncompressed"
I think it's a WAV wrapped in a FLAC.  I could be wrong.

EZ CD Audio has that option too.
EZ CD Audio Converter / FLAC or WavPack

Re: FLAC v1.3.3

Reply #144 –
Quote from: soundping on
"uncompressed"
I think it's a WAV wrapped in a FLAC.  I could be wrong.
Yep, you are  ;)  I don't think that is even possible, but read: https://forum.dbpoweramp.com/showthread.php?45797-Flac-uncompressed-question
Apparently the "uncompressed" FLAC cannot switch off FLAC's "wasted bits" feature. I.e. if you fit a 16-bit signal into a 24-bit WAV (or AIFF), it will pad up eight bits with zeroes; flac.exe will notice that the eight bits are "wasted" and treat it as a 16 bit signal (this is in each subframe header, the file will be flagged as 24-bit). Other codecs offer that as well, more in section 2.3 of http://www.audiograaf.nl/losslesstest/Lossless%20audio%20codec%20comparison%20-%20revision%204.pdf . There seems no way to pass options to the reference flac.exe to force wasted bits to zero.

Quote from: soundping
EZ
Unsurprising. Whenever that guy sees a buzzword at dBpoweramp, he copies it - to the point of calling his ripping engine "AccurateCDDA" to leech on AccurateRip.
Just avoid.

Re: FLAC v1.3.3

Reply #145 –
EZ CD is also currently the only way to use Fraunhofer's xHE-AAC encoder. I asked Fraunhofer. No, they are not into selling personal licenses.

Re: FLAC v1.3.3

Reply #146 –
I have created a FLAC 64 bit installer with user-friendly functions:















Re: FLAC v1.3.3

Reply #147 –
I have created a FLAC 64 bit installer with user-friendly functions:















Re: FLAC v1.3.3

Reply #149 –
End of 2021.
No official stable release for the most popular operating system in world.
Heh...