(2012-09-11, 04:38)DDDamian Wrote: (2012-09-10, 14:52)puntloos Wrote: More specifically, my amplifier supports 7.1 multichannel, 192Khz, 24bit LPCM. Wouldn't it be amazing to decode incoming audio to the same Khz and 24bit (since upsampling is a bad idea, but upconverting is lossless, and applying processing at higher bit depth introduces less artefacts, then wrap the result in a nice package for the receiver?
Even more amazing to just ouput it as-is. Remember you are talking about your specific requirements. We have to please as many as possible (ourselves especially lol), and very few have the above who do not also have DTS-MA/TrueHD. So it's a small subset.
Actually, my receiver supports everything, TrueHD, DTS-MA 192/24 etc. My goal is not trying to bend you guys into building something thats only useful for me, but in fact to build what is I believe is objectively the best for everybody
- please allow me to explain and hopefully convince you =)
My request comes purely from the observation that the very useful DRC, volume and equalization controls don't work in many situations and counter-intuitively, sound quality improves too by using LPCM. By this I mean both gapless playback, as well as actual objective sound quality (yes, really, I will explain).
LPCM is the magic bullet
First of all though, I realize there are 4 potential meta-downsides to implementing LPCM
- Quality Loss Due to Processing
-> While undeniably true if you're being very picky (and as an audiophile, I typically am.. ), 16 bits sources can be upconverted to 24bit without any quality loss, and at 24bit, applying simple volume attenuation will arguably cause only inaudible quality loss anyway. Of course this assumes you don't downconvert back to 16, but if a receiver supports LPCM, it usually supports 24bits.
-> If you do not DRC or attenuate or equalize, there is completely no quality loss.
- CPU Cost
-> This one I don't know that much about, but in "most" current XBMC systems video decoding is hardware accelerated anyway, so I imagine that most systems have enough CPU headroom to decode, especially since there is no need to do much work encoding (I imagine wrapping raw LPCM is a fairly lightweight process compared to applying lossy compression like AC3/DTS.).
- Programming Cost
-> Yes I am aware that you guys are busy, so I'm not claiming this should be your #1 priority, but when it comes to "Return on Investment", this one is pretty good: FFMpeg can already everything out of the box, all that is needed (I know... I know.. speaking as a non-contributor - my coding days are way behind me - this is easy for me to say) is to wire it up the right way. On the returns side though, major benefits as listed above. DRC, Volume and audio quality.
- Loss of some flexibility when selecting audio streams
-> Not familiar enough with the internals, but XBMC already has OSD language controls, so yeah the user should use these. In the background, ideally only strip out the selected audio stream and postprocess that, and pass other language streams etc unchanged so the user could even use the receivers language selector too if he really wants to.
Quote:It is planned at some point to have a "play-everything-maxed-out" mode which will upconvert and upsample
NOOOO. Do not upsample.
Monty - The lead coder of Vorbis on why 192/24 is lower quality than 44/16
Ultrasonics are nasty.
That said, purely from a usability perspective I would say that the ideal configuration page would allow the user to:
1/ Be able to specify it's receiver's specs. This is 95% done.
2/ Turn on or off postprocessing. Either XBMC would work to delivery bit-precise, as the movie soundman intended to your receiver, or enable volume control, DRC, equalization in all cases that are feasible (I think there's no DTS-MA software decoder yet?).
From these settings, XBMC can determine the ideal output.
In my opinion what people actually don't realize (given my LPCM points) is that in many cases, delivering LPCM to a receiver is actually preferable to delivering the encoded format. Bitstreaming is purely a buzzword that people want without good reason. Ooh. the pretty TrueHD light on my receiver is lit! R0x0rz!
Instead, in the real world, FFMpeg is getting better every day, while your receiver's decoder is usually fixed in time. By now, I have little doubt that
FFMpeg is better at decoding AC3 than my 5 year old receiver, and pairing that with the fact that enabling high-frequency components (i.e. 'decoders') inside the receiver generates
extra EM fields right next to your analog amplifier, that can easily be transferred into your analog audio signal. Negligible? Perhaps, but if you are pretending to be an audiophile, these minute details actually favor LPCM =)
As a note about legacy receivers, and personal choice, these options might be useful
- Postprocess, then encode to AC3
-> Given that as I said AC3 decoders HAVE to support night mode, it might be an idea to transcode everything to high-bitrate AC3 and then have the night mode on your receiver work (presumably some people like to use their receiver's remote..)
- Postprocess, then encode to DTS
-> If receivers don't support LPCM, then DTS is better than AC3 (quality-wise) and they still get to have DRC and Volume through the XBMC postprocessing
Quote:everything to the best your device can handle, but that's more for seemless gapless music playback than what you propose.
Yeah gapless is just one of the side benefits of my proposal
While I'm at it allow me to suggest the right approach to user messaging and feature discoverability (can you guess what my daytime job is?
)
- Postprocessing on/off
-> Default it to on. You gain gapless for free and I hope I've convinced you there is no quality loss if you do, as long as you don't actually enable DRC and volume.
-> The first time the user hits the volume or DRC button, pop up a one-time dialog explaining the quality implications and explain to the user he/she shouldn't care because XBMC is so amazing =)
- Night Mode / DRC
-> Default to off but since it would work in most cases, feature it prominently on the interface!
- CPU overload
-> XBMC can probably fairly easily work out if the audio postprocessing is possibly causing the CPU to run out of steam. If CPU > 95% postprocessing is on then pop up a message suggesting turning it off if the user is noticing hiccups
- Upsampling
-> Don't include it. It is NEVER an improvement. One can argue about processing TrueHD at 192Khz versus downsampling which would possibly improve quality and definitely improve CPU usage.
Quote:And it won't be until after Frodo final - there's only a few more features to be added - the rest is bug-fixes until then.
Motion to include my suggestion as one of those few features. =)
Quote: (2012-09-10, 14:52)puntloos Wrote: Every AC3 capable endpoint has a night mode. It's a requirement for being able to carry the AC3 label. My beef with AC3 is that I don't want to decode lossy to "lossless" and then re-encode it with another pass of lossy.
Can't blame you - i wouldn't want to either. Why would you need to with good hardware??
Agreed. I want the benefits of processing without the downsides. Hence LPCM =)
Quote:You don't have Frodo - it isn't out yet. You have the work in progress which will be Frodo if we don't have to answer too many posts.
Nicely put
Hope the above all makes sense, and I didn't waste much of your time, but as you can imagine it probably took me more time to write this than for you to read it.
It is my firm belief from my microelectronics, computer science background that my proposed solution is the theoretically optimal situation, and I hope I've made a coherent point that implementing it is actually worth your while.
