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.4 (Read 51255 times) previous topic - next topic - Topic derived from FLAC v1.3.3
0 Members and 1 Guest are viewing this topic.

Re: FLAC v1.3.4

Reply #100
a quick Google search with keywords like 1536kHz DAC, there are about 367,000 results with links to actual products supporting 32-bit 1536kHz input.
Google fools itself. Go to the bottom of the page and click at page number six.
https://www.google.com/search?q=(%221536+kHz%22+OR+%221536kHz%22)+AND+%22DAC%22&start=50
Drop the "&start=50" and I also get 367 k. But scrolling to the end, it is only 56. Click for the search to include the alike-hits, and I get 236 of them in total.

Replace both 1536 by 768 and the 56 grow to 88 and the 236 to 389.

Re: FLAC v1.3.4

Reply #101
Google fools itself. Go to the bottom of the page and click at page number six.
https://www.google.com/search?q=(%221536+kHz%22+OR+%221536kHz%22)+AND+%22DAC%22&start=50
Drop the "&start=50" and I also get 367 k. But scrolling to the end, it is only 56. Click for the search to include the alike-hits, and I get 236 of them in total.

Replace both 1536 by 768 and the 56 grow to 88 and the 236 to 389.
Don't know about Google's algorithms and quirks but it is rather popular for DACs (as a whole product) to support 32-bit 1536kHz via I2S with HDMI/RJ45 and such, providing the DAC chips themselves support the format.

Higher bit-depth or PCM sample rates are much less popular, perhaps require custom chips instead of generic ones.

Quote
That is a reason to use WavPack. It handles 4 GiHz (like WAVE does).
After receiving your comment about some Sound Liaison files, I tried to find a better way to skip unknown RIFF chunks. Another thing is I also added a check to nAvgBytesPerSec in WAVEFORMAT. nAvgBytesPerSec is a 32-bit value defining the average byte (not bit) rate of a file and therefore the maximum bitrate of a file must be smaller than 2 ^ 32 * 8. My check is ensure the combination of sample rate, bit depth and channel count in a uncompressed file does not exceed the maximum allowed nAvgBytesPerSec.

I found that quite a number of software don't check this and treat sample rate, bit depth and channel counts separately, and the combination can well exceed what nAvgBytesPerSec allows.

Also, I found that Audition 1.5 which I use shows negative sample rates for values beyond 2 ^ 31.


Re: FLAC v1.3.4

Reply #103
Here's one such release on 768kHz.

Wow... what a waste of space, recources, time, money. It contains almost HF-Noise.



The best part is some of their 24-bit files are actually 16-bit. Download the archive and check out the readme file.
https://hydrogenaud.io/index.php/topic,114816.msg1010860.html#msg1010860

Re: FLAC v1.3.4

Reply #104
almost HF-Noise
An extra octave of it added by going DXD to analog tape to double-the-Hz digital. Best of both worlds! ;-)
Apparently, all PR is good PR.

The best part is some of their 24-bit files are actually 16-bit.
Unlike an-octave-or-four of tape hiss, that need not cost anything; some of them are so cleanly 16-padded-to-24 that FLAC compresses it away.  (As well known: FLAC/WavPack/TAK/OptimFROG handle wasted bits. ALAC/Monkey's/TTA don't.)

Re: FLAC v1.3.4

Reply #105
Just for those curious: I'm not adding 32-bit int and >655350Hz handling to FLAC because I think it has any (audible) benefit. I also am not getting paid for this.

The only reason these features are added to libFLAC is because the standard allows them. Currently an IETF working group is writing a document on the FLAC specification which should at some point become a standards track RFC. One of the requirements of becoming a proper IETF standard is that there should be at least two implementations of each part of the standard. That means that IMO at least libFLAC should be able to use all features of the FLAC format. That means adding support for 32-bit PCM, but it will also mean libFLAC should at some point support variable blocksize encoding. (I can't yet guarantee that using a variable blocksize will be any improvement though)
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #106
In search of some older 32 bit files, I did come across some WAVs that were previously (and probably still are) incompressible, however due to another reason entirely - they are 24/768kHz, and the max sampling rate the FLAC encoder allows is 655.35kHz
This limit has been raised to 1,048,575Hz in April, which is the true limit of the format. The previous 655,350Hz was the 'streamable' limit of the format, for some reason the reference encoder (libFLAC) didn't accept anything with a higher samplerate than that.

Quote
Not that I expect any commercial music releases to ever use such a high sampling rate, nor do I think it would have any practical application to most people, but it does seem that 768kHz is somewhat of a standard sampling rate for audio analysis and some other professional applications. It would be nice to have them compressible as well, as it would seem to be a much more appropriate format for this purpose.
Here's one such release on 768kHz.

Quote
I do know that the Domesday Duplicator / ld-decode folks are using FLAC compression in some nonstandard manner for recordings of RF captures sampled at 33.5MHz (yes, with an M) so theoretically this should be possible with the standard encoder too, if not for the limitation being baked in.
Yes, I've recommended them to place the sample rate in a vorbis comment or something similar. The samplerate is nothing to the FLAC format but a number, it doesn't do anything with it except including it in the frame headers and giving it back on decoding. It really is only necessary to be able to properly play back a file.

Beautiful, I was totally unaware of that recent change as well! I’ll have to give these 24/768 files a shot on the newer compile now too.

The only practical application I know of for such high sampling rates in terms of music production is capturing the bias signal present on tape to digitally correct temporal distortions, ie. Plangent Process

I don’t foresee a time when there is any legitimate usage of that as a deliverable format. There will always be some nutty small label trying to experiment, but the one pointlessly printing digital to tape and back seems like they are alone in this regard and probably will be for some time…

As far as I am aware there is no PCM DAC that can truly operate at such frequency anyhow. Anything advertising sampling rates higher than 192kHZ is with all certainty using a delta-sigma chip. The non-oversampling converters capable of natively operating at 192kHz are already very few and far between.

Re: FLAC v1.3.4

Reply #107
Celemony Capstan doesn't require high sample rates to grab the bias signal, which means in case the original tape is already damaged or unavailable, the software can still analyze the audio data of an existing file to do the restoration.
https://www.soundonsound.com/reviews/celemony-capstan
https://www.celemony.com/en/capstan

For generic ADC chips, the 15+ years old TI PCM4222 for example has a 6-bit modulator running at maximum 6.912MHz. Of course, this requires a customized controller accompanied with the ADC chip, not via typical PCM or DSD methods. Judge from the age, processing power is indeed not a concern, but hiring someone to code the controller for a potentially very small market could be expensive.
X

Re: FLAC v1.3.4

Reply #108
FLAC 1.3.4 git-cbb039d, including dlls, now at Rarewares. :)

Re: FLAC v1.3.4

Reply #109
I’ll have to give these 24/768 files a shot on the newer compile now too.

I've posted some results already for the free file - now including -5 and -8p from NetRanger's build.

The "TransposedTo192k.nometadata" files are just that I changed the sampling rate in the .wav file and removed the 1265 MB metadata - reason for changing the sampling is to get a comparable TAK.  The 1265 makes an "error" in comparing FLAC/ALAC/TTA that don't (by default) store foreign metadata, to the others
Code: [Select]
969 129 022 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.wav
967 864 784 TransposedTo192k.nometadata.wav
778 734 183 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.7z
703 857 334 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.fj0.wv
673 615 462 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.fast.ape
666 519 575 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.tta
663 164 138 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.hx1.wv
653 129 918 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.normal.ape
652 911 634 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.high.ape
650 586 694 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.m4a
649 644 648 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.-5.flac
649 459 286 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.extrahigh.ape
645 055 381 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.als-at-default-in-.mp4
643 043 026 TransposedTo192k.nometadata.-8p.flac
642 946 998 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.-8p.flac
641 225 096 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.wv-hhx6.=37min=.wv
640 902 644 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.wv480-hhx6.=40min=.wv
637 544 165 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.-z3.als
634 689 178 TransposedTo192k.nometadata.-p4m.tak
634 179 909 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.-7-t2.ALS-in.mp4
632 366 679 Let The Good Times Roll - Carmen Gomes Inc - Free 768kHz.ofr.max.ofr

(WavPack 5.40 is a bit faster than 4.80. The slightly bigger files are due to the new format with checksummed blocks, enabling fast integrity verification without decoding.)




Re: FLAC v1.3.4

Reply #113
Thank you again NetRanger!

I finally got a chance to try this out however I still could not compress the 24/768kHz files I had. It immediately errored out both trying it with FLAC.exe directly as well as trying to start a conversion in Foobar. Not sure if it’s a “me” problem


Re: FLAC v1.3.4

Reply #115
You need to apply the --lax option. By command-line, you throw in " --lax " before or after all the other options.


Ahhh, therein lies the rub. Thank you for that!

Re: FLAC v1.3.4

Reply #116
Quote
The only practical application I know of for such high sampling rates in terms of music production is capturing the bias signal present on tape to digitally correct temporal distortions, ie. Plangent Process

Also, maybe for situations when it's not really about sound, just some physical processes, maybe radio frequency even. (archives/test cases for software-defined radio?) Possibly useful if the signal may share some statistical properties with that of sound, making it somewhat compressible by similar algorithms.
(But then, even ~1Mhz might not be a high enough upper limit)
a fan of AutoEq + Meier Crossfeed

 

Re: FLAC v1.3.4

Reply #117
Also, maybe for situations when it's not really about sound, just some physical processes, maybe radio frequency even. (archives/test cases for software-defined radio?) Possibly useful if the signal may share some statistical properties with that of sound, making it somewhat compressible by similar algorithms.
(But then, even ~1Mhz might not be a high enough upper limit)
--> over at the WavPack forum: https://hydrogenaud.io/index.php/topic,122626

WavPack handles "any .wav" sampling frequency, that is integers up to 4 GiHz. That covers most amateur radio bands. (There are radio bands above https://en.wikipedia.org/wiki/9-centimeter_band , and then ... well, out of luck :-o)



Re: FLAC v1.3.4

Reply #120
FLAC git-3022dad8 20220806
Built on August 06, 2022, GCC 12.1.0
The 64-bit build includes encoder speedups for CPUs with FMA (basically any CPU with AVX2) to help compensate for the speed loss that resulted from the autocorrelation precision increase. When https://github.com/xiph/flac/pull/407 is merged, I hope most recent Intel/AMD CPUs (running the 64-bit binary) will see encoding speeds similar to 1.3.4 but with higher compression.

Music: sounds arranged such that they construct feelings.


Re: FLAC v1.3.4

Reply #122
That's the idea, but I'm still working on a documentation overhaul and there are some fuzz results that need a fix.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #123
Is there a summary of FLAC improvements somewhere that is more direct than the changelog on Xiph.org? IIRC the main improvements after the move to Xiph were related to multichannel support, but FLAC has had no major changes that broke backwards compatibility with older versions and no major improvements in compression efficiency for CDDA, either. Is that an outdated assessment?

Re: FLAC v1.3.4

Reply #124

As far as I am aware there is no PCM DAC that can truly operate at such frequency anyhow. Anything advertising sampling rates higher than 192kHZ is with all certainty using a delta-sigma chip. The non-oversampling converters capable of natively operating at 192kHz are already very few and far between.

Several GHz are now okay for a DAC and 192kHz is very low. Look at this:

https://www.keysight.com/us/en/product/M9484C/m9484c-vxg-vector-signal-generator.html

3 GHz in 16 bits. I can't believe it  :D