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.
Recent Posts
1
Digital A/V News / Reviewers Wanted
Last post by omasciarotte -
Hey folks,

We at MAAT GmbH make digital audio products mostly used by mastering engineers. We also make a few products, like DRMeter, DROffline MkII, MAATgo, and our equalizers, that are also loved by audio enthusiasts worldwide.

This is a pitch to all you connoisseurs out there who are curious about:

  • adding pristine tone control or system voicing to your signal chain
  • adding what pros call “monitor controls”

All our plug–ins are delivered in the cross–platform VST 2 & 3 formats, along with AU and AAX. That implies you already are using a plug–in host that recognizes one of those formats…

Interested? Give me a shout at oliver at our maat dot digital domain.

P.S. — Sorry about the woefully out of date signature. No matter what I’ve tried, I cannot get signature updates to “stick.”
2
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
HALAC 0.2.8
Encoders, Decoders, Libraries and Player (Both Windows and Linux)
https://github.com/Hakan-Abbas/HALAC...ssion/releases
https://github.com/Hakan-Abbas/HALAC-Audio-Player

X X
Code: [Select]
//HALAC 0.2.8 Library Function Prototypes
extern "C" HALAC_PLAYER_API const bool __stdcall CHECK_HALAC(const char* data);
extern "C" HALAC_PLAYER_API const char* __stdcall GET_HALAC_VERSION();
extern "C" HALAC_PLAYER_API char* __stdcall GET_WAV(const char* data, unsigned short thread_count);
extern "C" HALAC_PLAYER_API char* __stdcall GET_WAV_FRAME(const char* data, unsigned int first_frame_no, unsigned int last_frame_no, unsigned short thread_count); // 0...(frame_size -1)
extern "C" HALAC_PLAYER_API char* __stdcall GET_RAW_FRAME(const char* data, unsigned int halac_frame_size, unsigned int wav_frame_size, unsigned char halac_mode, unsigned short channel_count, unsigned short sample_bit, unsigned short thread_count);
 
extern "C" HALAC_PLAYER_API char* __stdcall GET_WAV_HEADER(const char* data, unsigned short header_size);
extern "C" HALAC_PLAYER_API const unsigned short __stdcall GET_WAV_HEADER_SIZE(const char* data);
extern "C" HALAC_PLAYER_API const int __stdcall GET_METADATA_SIZE(const char* data); // Negative values give the length of metadata at the end of the file.
extern "C" HALAC_PLAYER_API const char* __stdcall GET_METADATA(const char* data, int metadata_size);
extern "C" HALAC_PLAYER_API const unsigned char __stdcall GET_HALAC_MODE(const char* data); // normal or fast
extern "C" HALAC_PLAYER_API const unsigned long long __stdcall GET_WAV_FILE_SIZE(const char* data);
extern "C" HALAC_PLAYER_API const unsigned long long __stdcall GET_WAV_DATA_SIZE(const char* data);
extern "C" HALAC_PLAYER_API const unsigned short __stdcall GET_CHANNELS(const char* data);
extern "C" HALAC_PLAYER_API const unsigned int __stdcall GET_SAMPLE_RATE(const char* data);
extern "C" HALAC_PLAYER_API const unsigned short __stdcall GET_BIT_COUNT(const char* data);
extern "C" HALAC_PLAYER_API const unsigned int __stdcall GET_HALAC_FRAME_COUNT(const char* data); //Number of compressed blocks
extern "C" HALAC_PLAYER_API const unsigned int* __stdcall GET_HALAC_FRAME_SIZES(const char* data); // Lengths of compressed blocks
extern "C" HALAC_PLAYER_API const unsigned int __stdcall GET_WAV_FRAME_SIZE(); // 1024*1024 bytes except for the last frame
extern "C" HALAC_PLAYER_API const unsigned int __stdcall GET_WAV_LAST_FRAME_SIZE(const char* data);
 
extern "C" HALAC_PLAYER_API void __stdcall DELETE_WAV_MEMORY();
7
3rd Party Plugins - (fb2k) / Re: Biography Discussion
Last post by FritzLn -
I've noticed that the plugin doesn't seem to handle certain special characters correctly.

For instance, i get the following error in my console when attempting to retrieve the album review for: https://www.allmusic.com/album/closure-continuation-mw0003617672

Quote
Biography Server: allmusic review: Closure/Continuation / Porcupine Tree: not found

Is there a workaround or is this a bug? I'd create a github issue, but there doesn't appear to be a way to do it.
9
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by ngs428 -
Quote from: Case on
Quote from: ngs428 on
Quote from: Case on
Would you be interested in more statistics in the output? Just knowing that samples clip doesn't yet tell how bad it is. Exceeding the full scale by 0.1 dB would not matter at all, but exceeding it by 3 dB could be a problem.
I could for example log how large percentage of clipping exceeded full scale by 1 dB, how much by 2 dB, etc.

After reading this, it got me thinking of what the "Clipping Samples" or "Album Clipping" actually tells us.  I have some tracks that show thousands of clips and I have only scanned a handful of tracks, are the clips only 0.1 dB over, hard to say...  Understanding how far the clip exceeds full scale by % of clips makes sense.  Similar to what you described.  % clips >1dB, % clips >2dB, % clips >3dB, etc., would give a user an understating of the impact of the clipping.
I spent some time today to think about what kind of statistics to gather from clipping, here's an experimental implementation: https://foobar.hyv.fi/foo_truepeak_clip_report_testing.fb2k-component
I hope people don't quote this link as the component will be nuked once testing is done, leaving quotes with bad links behind.

The new experimental statistics aren't shown on the result dialog or tagged, they are only printed to foobar's console. So it's best to test that with only one track.

Example results:
Code: [Select]
True Peak Scanning track: G:\Music\Lossless\Metallica\(2008) Death Magnetic\05. All Nightmare Long.flac
Oversampling to 352800 Hz with Resampler (SoX)
Clip stats: ch0: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 16.0000000 (0:00.000 s), total clipping samples: 377258 (0:01.069 s)
Clip stats: ch1: peak: 1.2273319 (1.7792406 dB), pos: 0:19.988, max clip rms: 1.0105605 dB, pos: 1:01.660, max consecutive clipping samples: 17.0000000 (0:00.000 s), total clipping samples: 781139 (0:02.214 s)
Clip stats track:: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 17 (0:00.000 s), total clipping: 1158397 (0:03.283 s)
Clip histogram:
peak at 0.0 - 0.1 dB: 1038987 samples (89.69 %)
peak at 0.1 - 0.2 dB: 78387 samples (6.77 %)
peak at 0.2 - 0.3 dB: 21630 samples (1.87 %)
peak at 0.3 - 0.4 dB: 8597 samples (0.74 %)
peak at 0.4 - 0.5 dB: 4253 samples (0.37 %)
peak at 0.5 - 0.6 dB: 2362 samples (0.20 %)
peak at 0.6 - 0.7 dB: 1473 samples (0.13 %)
peak at 0.7 - 0.8 dB: 910 samples (0.08 %)
peak at 0.8 - 0.9 dB: 605 samples (0.05 %)
peak at 0.9 - 1.0 dB: 394 samples (0.03 %)
peak at 1.0 - 1.1 dB: 293 samples (0.03 %)
peak at 1.1 - 1.2 dB: 188 samples (0.02 %)
peak at 1.2 - 1.3 dB: 138 samples (0.01 %)
peak at 1.3 - 1.4 dB: 76 samples (0.01 %)
peak at 1.4 - 1.5 dB: 49 samples (0.00 %)
peak at 1.5 - 1.6 dB: 23 samples (0.00 %)
peak at 1.6 - 1.7 dB: 13 samples (0.00 %)
peak at 1.7 - 1.8 dB: 5 samples (0.00 %)
peak at 1.8 - 1.9 dB: 4 samples (0.00 %)
peak at 2.0 - 2.1 dB: 4 samples (0.00 %)
peak at 2.1 - 2.2 dB: 3 samples (0.00 %)
peak at 2.2 - 2.3 dB: 2 samples (0.00 %)
peak at 1.9 - 2.0 dB: 1 samples (0.00 %)

I think you are on to something.  How granular the histogram has to be is a good question.  Do we need it by 0.1?  Is sure does show that your file have a ton of clips, but approx 90% are 0.1 or lower.  I think this helps explain the impact of the clip result.

Example results:
Code: [Select]
Oversampling to 192000 Hz with Resampler (SoX)
Clip stats: ch0: peak: 1.0216434 (0.1859869 dB), pos: 0:34.500, max clip rms: -0.0615525 dB, pos: 0:32.646, max consecutive clipping samples: 1.0000000 (0:00.000 s), total clipping samples: 3 (0:00.000 s)
Clip stats: ch1: peak: 1.0251275 (0.2155575 dB), pos: 0:34.500, max clip rms: -0.0170493 dB, pos: 0:26.200, max consecutive clipping samples: 1.0000000 (0:00.000 s), total clipping samples: 2 (0:00.000 s)
Clip stats track:: peak: 1.0251275 (0.2155575 dB), pos: 0:34.500, max clip rms: -0.0170493 dB, pos: 0:26.200, max consecutive clipping samples: 1 (0:00.000 s), total clipping: 5 (0:00.000 s)
Clip histogram:
peak at 0.0 - 0.1 dB: 2 samples (40.00 %)
peak at 0.1 - 0.2 dB: 2 samples (40.00 %)
peak at 0.2 - 0.3 dB: 1 samples (20.00 %)
True Peaks calculated in: 0:01.280, speed: 31.15x

How this is presented is another story.  You can't write 20 tag values for this..  Output .txt file?  That would get to be a lot of data.  I like what you have here.  Thanks for spending time on it. 


I see you are Oversampling to 352800.  I left mine at the default of 192000.  Higher the more accurate and most of my files are 44100, so I could probably look to change it to 352800....  Factor of 8.  I thought it would pick an even factor when oversampling.  My 44.1k resampled to 192k.
10
Other Lossy Codecs / Re: Quite OK Audio (QOA)... anyone ?
Last post by Porcus -
First, QOA wasn't constructed to be transparent. It was intended to be "Quite OK" at very light decoding load. But I guess you know.

"Obviously" such a quantization calls for a noise shaping algorithm. How to round off each sample residual to one of the values implied by the dequant table.
Given that the format has been published and frozen - a decoder has found its way into ffmpeg too - then if you want a revision you probably need to (I) give a case for the need for it and (II) what does actually improve.  For (I), not only "but it could sound better" but also why that cannot be solved by noise shaping upon encoding; for (II), not only "I want another bit in the dequant table and I'm willing to reduce the 8 bytes slice coverage to only 15 samples", but what values for the new table.