Skip to main content
Recent Posts
Scientific Discussion / Re: Audio Summing Algorithm
Last post by jsdyson -
Obviously, in the worst case (as noted above), one needs to reduce the sum of the levels by the count of sources.  However, there are some possible modifications of that rule if you have control of the result (and just want to avoid blowing out your ears before tuning the levels later on.)   So here are the mathematical rules:

1)  in the general case, you need to divide the level by the count of inputs.   when doing this math, you need to be careful about underflow (esp if not properly dithered) and overflow during the actual summation.

2) if you are summing multiple sound sources with the same song, mostly uncorrelated -- then an approximation using sqrt(N) instead of N might still overflow, but can come fairly close.  This will NOT work in the worst case, but gives you an idea of a starting point for each individual instance.

3) If you are summing totally independent sources (e.g. multiple bands of frequencies that do not overlap), then the sqrt(N) rule comes closer to correct.

I am NOT meaning to confuse the hard rule about dividing by 'N", but rather trying to show the subtle nature of the statistics involved.

AGAIN, the initial answer (divide by N) is perfectly accurate -- if you never can overflow (including during the math), then you need to divide each input by N before doing the summation.   If you can 'overflow' during the summation (happen to temporarily be using floating point or larger range number), then you can do the summation and then the division (it is likely to maintain quality better if you can do so and avoid the overflow of the temporary value.)   This also applies in the analog situation, where it is better to keep the signals as strong as you can for as long as you can -- however avoiding overflow (or the analog 'clipping') of the circuit in every part of the circuit.

Isn't it amazing about how complicated a simple 'putting together' of multiple signals can be?  (It really isn't that complicated, but it is always a good idea to keep aware of what is going on in the circuit or software.)  I guess that I just might be making it complicated, but really trying to help with 'thinking' and trying to help new thinkers practice their learning skills!!!

Scientific Discussion / Re: Have a working 'expander' based on DolbyA (not same design) -- works well.
Last post by jsdyson -
I haven't used it myself but I contacted a person that uses Dolby A and I Think he has contacted you. I really appreciate what you are doing even though I have not used your software since I do not have any Dolby A encoded material. I do look forward to try out your future compressor you talked about earlier. I also love that you software is available to Linux and hopefully your compressor can be a LV2 or/and VST plugin.

FIRSTLY:  if there is more interest, I can make the compressor available soon -- just needs to be updated with better code from DolbyA and expander.  If you want to hear the results of a relatively mild run of the compressor, listen to SOS-DAfull-finalized.mp3 on the repository:
The file SOS-DAfull-finalized.mp3 has been DolbyA decoded, expanded (to remove some of the old compression artifacts), and re-compressed/limited with the modern compressor at a fairly controlled level.  If you are really, really interested, I can make a limited version of the compressor/limiter available for Windows64 in about a week -- but it would be command line oriented (lots of options/tuning to get that special sound), and as a side-bonus the expander is built-in also.  The bad news is that heavy baggage runs a little slowly, and the compressor & expander cannot run realtime.  However, on a relatively fast machine, the compressor running alone usually has NO trouble running in realtime at 96k.  This MIGHT change as I move some of the filtering from the expander, so AS YOU CAN SEE, the code is still in flux.

One thing -- I truly do not know what you know or even about what you know, so PLEASE forgive me if this might seem rude...  Before 1yr ago, I would have also said that I had no DolbyA encoded material, yet a large amount of my music collection WERE DEFINITELY DolbyA encoded...  For example, I had my ABBA collection for over 10yrs (really, really, long time), yet knowing what I know now, and listening to it, I kind of 'whack' the side of my own head now realizing that my ABBA collection IS DolbyA encoded.  Here is an example of my UNINTENTIONAL DolbyA material collection (likely well over 1/2 of everything I own including):  Petula Clark collection of 4 CDs, massive Carpenters collection, a copy of ABBA Gold, 3 Simon&Garfunkel albums, 2 Linda Ronstadt albums, Fleetwood Mac Rumors, Christopher Cross Album, massive Olivia Newton John collection, Herb Alpert Album, Herb Alpert & Brasil66 Album, Burt Bacharach set of two albums, Dionne Warwick Album, Chicago CD, Queen CD, Carly Simon CD, 2 Anne Murray albums, Bangles CD, Bananarama CD, Moody Blues CD, The Cars, Suzanne Vega, Paul McCartney & wings from HDtracks, Carpenters from HDtracks...

My point in listing these -- you (or someone) just might (more likely than not) REALLY have a DolbyA encoded album (not vinyl, but CD or electronic.)  This has been a very common thing, because I have almost had to check my sanity when I realized this.  I have gone back directly to the CD source and lo&behold a CD that I might have purchased over 5yrs ago or something I downloaded deep in the past has been left DolbyA encoded.

I did NOT have to carefully select the material that I put on my repository, because I have found that more likely than not that a given piece of material that I have TRULY, REALLY benefits from DolbyA decoding.  I honestly cannot claim that every item that seems to be DolbyA encoded really is -- but I have some traceably DolbyA encoded material and it really doesn't sound much different in 'compressed' sound and HF emphasis from the material that I have given as examples.

The only reason why the material can be left DolbyA encoded is that the result isn't really all that fatal (just a bit too much HF empahsis, too much of a compressed sound, and more hiss than there should be on older recordings from older tape formulations and tape machines..)

Some of my collection initially sound quite nasty, but then turns into audiophlie grade upon decoding -- REALLY!!!

If you don't have anything that is DolbyA encoded, I understand...  But if you have a large electronic or CD sourced collection (or a moderate sized one like mine), then there is at least 1/2 of the selections that benefit from DolbyA decoding.  I'd estimate that at least 50% -75% of my collection is almost provably DolbyA encoded, and perhaps 10% is questionable either way (might be sidechain compressed because of excess HF loss but no expansion dynamics problems.)  The rest of the 15% is NOT DolbyA encoded.

Wrt my compressor (and possibly expander project) -- my compressor project is essentially on hold for two reasons 1) percieved lack of interest, 2) I have learned a hell of a lot on the expander and psuedo-DolbyA project -- need to feed back info into the compressor project.  Note my comment about the compressor project above.

Wrt my general purpose expander project -- it isn't really 'on hold', but has been in development on an ongoing basis during the psuedo-DolbyA project.  Initially, the psuedo-DolbyA was part of the expander project, but I found that the pseudo-DolbyA design requirements to be so very specific, that I seperated out the high level portions of the psuedo-DolbyA.  However, the vastly improved anti-intermodulation dynamics techniques that I have used to make the psuedo-DolbyA work so beautifully (clean, clear, no roughness) are being fed back primarily into the expander project and also secondarily the compressor project.

I already had pretty darned good dynamics classes (attack/decay/gain-riding/etc) in C++ for numerous purposes when starting the expander & DolbyA projects -- the compressor was the basis for all of the work.  There was already A LOT of intermodulation mitigation and well controlled attack/release characteristics,.  However, given my own sense of perfection, I have been striving for perfection in the DolbyA project -- FURTHER MORE STRONGLY controlling the mathematically unnecessary intermodulation effects -- thereby producing a DolbyA decoder that changes the character of the sound back to before the DolbyA encoding. The pseudo-DolbyA decoder has few of the typical artifacts of either SW compression/expansion or real HW compression/expansion.  I think that the ONLY  intermodulation distortions left over on the psuedo-DolbyA is greatly attenuated and the sidebands are limited to below about 50Hz wide on the LF bands, and 450Hz wide in the midrange bands and 1000Hz wide in the HF bands.   Even that those very significant limits (probably 10dB-20dB down at those bandwidths), the technically unneeded modulation products are attenuated even for the nearby sidebands.  I have successfully controlled the intermodulation without fatally affecting the COMPATIBLE attack/delay times (was quite a feat to do correctly.)

Of course, one cannot do gain control without creating sidebands, so I had to leave the NECESSARY sidebands intact so that gain control would happen (yea, I know that there are tricks to move the sideband power over to one side and to make the distortion less noticeable, but that is too much work.)  For example, the compressor is built from a 3band compressor, an 8 band compressor, a 1 band last chance compressor, and a carefully crafted set of limiters (lots of stuff.)   The expander has 48 degrees of freedom in its gain control, and the vastly simpler pseudo DolbyA needs to meet really specific design criteria.
(BTW -- I am not exaggerating about the 48 degrees of freedom in the expander -- that is why the expander can provide 1:1.6 dB or higher expansion ratio without pumping.)

Oh well, I am really just trying to help, and anyone is willing to email me for access to the psuedo_DolbyA.  The SW will work as long as the OS/HW supports the code.  I am limiting the time for the offer for my own sanity, however :-).

Development - (fb2k) / [REQUEST] some useful features
Last post by Vittorio -
I don't know if this is the right forum to suggest new features...

1) Layout Switch
What I would like to see in new foobar versions is a simple switch functionality where I can switch between different layouts.
Currently I have the following workaround:
 - two tabs with different layouts
 - default layout = "foo_full" (maximized window)
   1. select tab with second layout "foo_min"
   2. double-click on window title to restore last size and position of the window
Now, the problem is No. 2: windows remembers the last state of an application window.
But what I'd like to have is a window with fixed size saved within the layout, which can only be changed in Layout Editor

2) Dynamic Artwork
Another idea is to set an stub image folder instead of just a single image with Dynamic Artwork for online media and files without cover.
Here is the concept:

- stub image folder: "C:\Users\John\AppData\Roaming\foobar2000\custom\artwork\"
- stub image file: "C:\Users\John\AppData\Roaming\foobar2000\custom\artwork\cd_cover.jpg"
- search patterns:
* - front.jpg
%artist% - %album%.jpg
%path% HAS "abacus.streamsiteXYZ" = abacusfm.jpg
%url% IS "" = deluxemusic.jpg
%artist% - Logo.jpg

artwork folder
Tiesto - Logo.jpg
Paul van Dyk - Logo.jpg

Support - (fb2k) / Windows Server 2016 Core - cannot get Foobar to open
Last post by jaynyc -
Did a clean installation of Windows 2016 Server Core.  Then added the Windows Media Foundation feature.

Then did a clean install of Foobar 1.4 (also tried 1.37) - and have tried both Standard and Portable installs.

First error says 'dsound.dll' is missing - so then I copy dsound.dll from Server 2016 Desktop Experience setup disc into the Foobar folder itself.  Then when I start Foobar again it says:
"Internal error - one or more of the installed components have been damaged."

What does that mean?   I haven't made any modifications to any of the components.

Thanks for any guidance.

Scientific Discussion / Re: Have a working 'expander' based on DolbyA (not same design) -- works well.
Last post by punkrockdude -
I haven't used it myself but I contacted a person that uses Dolby A and I Think he has contacted you. I really appreciate what you are doing even though I have not used your software since I do not have any Dolby A encoded material. I do look forward to try out your future compressor you talked about earlier. I also love that you software is available to Linux and hopefully your compressor can be a LV2 or/and VST plugin.
Scientific Discussion / Re: Have a working 'expander' based on DolbyA (not same design) -- works well.
Last post by jsdyson -
Regarding my disgust as to the quality of some of the available recordings, and finding that they were like left with DolbyA encoding intact -- yes.  That is 99% of the reason why I decided to write my own decoder.  I like challenges.  Plan to start working on SR (much more of a challenge) soon.

Regarding proof of operation/accuracy:  Yes -- an audio professional along with a golden-ears expert (for proof) has worked with me on perfecting the DolbyA decoder to be very compatible (but not bug compatible.)  So, SOME of the results of my SW decoder are better (cleaner/smoother sound -- minimal intermod -- no harmonic distortion from FET or diode gain control like the newer DolbyAs (FET) or the original (diode).)  The SW decoder has NONE of the typical defects of a SW compressor/expander regarding a harsh kind of sound.

I have been working on this for months, barely got it working credibly (kind of) about 2mos ago.  Then, a recording expert started participating (he wanted backup for his DolbyA units and probably computer environment software.)  He and I worked on making the gain curves nearly perfect (generally less than 0.5dB static error on all 4 channels, including the screwy 9k-20k channel.)
The SW doesn't use a simple attack/release scheme like a DolbyA schematic (and various patents) might imply, but uses something that strongly mitigates most mathematically unnecessary intermod, and produces a generally smoother/more accurate sound than either another commonly avaialble DolbyA SW decoder and real DolbyA units.  However, the audible attack/decay fits hand in glove with the real DolbyA.  (interestingly, even the distortion from the true LF on Simon&Garfunkel Scarborough Fair moduating with the gain control is removed because of the good matching for the decode operation.)

So, this has been acid tested with real (proven) DolbyA material and compared with real DolbyA units.  Also, very often, if material is NOT DolbyA encoded, but DolbyA is used to decode -- the sound becomes quite defective (including expander effects, terribly decreased HF, etc.)

So, if you listen to the examples on the repository, and find that the sound is reasonably good - then the original material was either DolbyA encoding somewhere in the processing chain or there was a similar sidechain compressor being used.

Please enjoy -- and the SW is available if you want.

SimplePortal 1.0.0 RC1 © 2008-2018