On Tue 6 December 2005 17:06, enduser wrote: > Dan Goodinson Wrote: > > enduser Wrote: > > > > There is no nice solution other than building in a quality peak > > limiter > > or running a scanner/filter on the digital data stream before it gets > > sent out the digital port for digital-to-digital situations. > > > > > > Would that not be the same as replay gain? My (admittedly limited) > > understanding of reply gain is that at encode (or after encode) you > > can > > build-in a sort of limiter to make the volume distribution more even > > across the track. Would this, in combination with a pre-amp, achieve > > the desired result? > > Replay gain is a means of taking disparate pieces of music, mastered at > different levels, and making them come out of your system at the same > volume level. The goal is to alleviate or eliminate your need to turn > the volume up and down on a per song ( or other frequent ) basis. > > Replay gain allows you to get your volume at a comfortable level and > enjoy your music. Unfortunately this comfortable level, when faced with > digital noise at max volume, is still enough to blow speakers. > > As digital data is present on the server (for the most part) before > being sent to the SB, what would be useful is a scanner that looks for > digital noise in the input stream.
I would be very interested in an algorithm that can distinguish noise from music. Please post any online references to this. > This would help the overall signal > chain quite a bit. Are you suggesting that the fault that you have experienced was introduced at the server and then streamed down to the Squeezebox whereupon the Squeezebox then output the supposedly valid yet somehow corrupt information out of the SP-DIF outputs which your DAC then output at a level that was higher than your normal music? I'd really like to refresh my memory of what this thread is *really* about. Can someone post a link to the original post, or any further post that actually defines what the problem that is being discussed is? (I'm reading this via email and regularly wipe the contents of my slim folder so I don't have the original post). > However, what is really needed is what radio stations use which is > essentially a real-time mastering engine. This includes compression, > equalization, gating, peak limiting, etc. This is the only way to get > quality sound from a wide variety of music. It requires a lot of grunt > to run such a mastering engine. If the SB system were a bit more open, > the sound streams could be bussed into existing PC-based digital > mastering tools and then out to the SB for on-location D/A. Maybe that > will happen one day ;-) Personally I can safely say that the day that Slim Devices add in further limiting to the already stupid levels applied as a matter of course by the mastering engineers of the world that I'll roll-back to my last version of the firmware that doesn't include this "feature" and stick with that. Music is already *way* too compressed and adding another level of compression would generally just make it worse. However, fortunately for yourself, the idea of plugging in compression into the system on the server (which I believe is what you are suggesting) is already a) completely open and b) under a license that lets you do exactly that so you should have no problem with it. Alex _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
