Wow, imagine my surprise when I tried to register here using an old throw-away handle only to find I'd already been here over a decade ago to post some moldy old desktop screenshots:
I can confirm it's present in the US pressing of the album too:
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'tshare 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...
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
|Test File // Version||Griever 7a35c528||Ozz 313ab58||john33 ce6dd6b||1.3.2|
|01. Take a Bow.flac 96/24||107 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 CD||31.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/24||83.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)|
|Total||222.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 bytes||0|
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]||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!