Relationship between loudness (volume level??) and Sound Quality

[OldTechie]

This might be of use. https://www.head-fi.org/threads/chro...-audio.747478/

That looks hopeful. I've tried it without any success on both the current release and the canary version (73.0.3665.0).

It seems the switch should still be present. see: https://peter.sh/experiments/chromiu...xclusive-audio. I don't know how you would select the correct device to send the audio to. In foobar2000 you select the output device:



I can't find the equivalent in Chrome. Maybe I'm missing some secret configuration.

[Dave2002]

I was hoping to rejoin this discussion, having found out more. Unfortunately having bought a new SSD device I've discovered that it's not possible to load it in my Humax FreeSat PVR. The PVR requires a FAT16/32 format drive. Despite all my efforts - several times, I've been unable to format the SSD into a format which the Humax box will recognise and accept. I tried various things - FAT, exFAT plus also repartitioning the SSD and then reformatting the partitions. All but given up on that now.

I may have another hard drive which is already formatted for the Humax, but I'll need to locate one before doing any further checking. Pity. I have had drives which work with that Humax device before - but never had this problem reformatting drives before.

In the meantime I've reformatted the SSD yet again in Apple file system formats. Currently it thinks it's a Mac OS Extended Journaled drive - I probably should have one more go to force it to APFS, though I think the OS might treat it as that anyway. Oh well, at least it still seems to work.

I'll be back!

[johnb]

Dave,

Has your Humax box an option to format an external HDD?

I don't know your Humax model but I would have thought Ext3 might be your best bet.

The Humax HDR Fox T2 can (reportedly) supports FAT32 and Ext3 for read/write. FAT32 is probably OK for USB pen drives but is too restrictive for HDDs. (The Hunax also supports NTFS but only for reading.)

[Dave2002]

johnb

I've never found an option to format any connected drive from my Humax PVR. Maybe other models have that, and perhaps this one does if there's a way to "break in" to it - it's probably a Linux variant underneath. EXT3 doesn't help much either, as then I'd have to have a machine which reads that, and although I did have one or two which ran Linux, I got rid of them. I'm not sure that I want to do that again either - though perhaps a Linux laptop might be useful if cheap enough.

It is possible that things have changed, both with the PVR and also the Apple machines, so that using formatting tools for older drive formats just doesn't work as they used to. If I have time I'll try formatting to FAT on one or two other machines, but as it seems less likely to work now, I'm not going to be in a hurry to experiment. The best bet is going to be to use a drive which already works, but they're not all immediately to hand.

See also this - https://hummy.tv/forum/threads/forma...xsat-hdr.3457/

[OldTechie]

Back to the --enable-exclusive-audio feature in Chrome.

I realise I shared a lack of understanding with ShrikeT in the Head-Fi thread. Looking through some of the issues on the Chromium development site, it looks as if the main thing they were trying to achieve with the feature was not exclusive mode as understood by foobar2000 or JRiver which can avoid re-sampling by the Windows mixer. They wanted to use WASAPI to reduce latency, probably to improve lip-sync with video. If that is the case, it is not surprising that it does not switch the audio device into exclusive mode.

The other thing that is now obvious to me, but I failed to realise it previously, is that there is a re-sampling audio mixer within Chrome (and every other browser.) The single audio output from the browser has the audio from all players running within it. I think it has a fixed 48kHz 16bit output in Chrome, regardless of the output of the player running inside it or the Windows output setting. So after the AAC audio is decoded, it is re-sampled twice before it gets to the DAC, and the re-sampling in Chrome is possibly truncated to 16 bit precision although the Windows mixer runs at 24 bit precision. I found some discussion about changing the mixer in Chrome to pick up the Windows settings but I think they did not get round to doing it.

There is no possibility of getting clean not re-sampled audio out of any browser. It would have to be coded so it could only run one audio player at once.

I can find the link address to the DASH .mpd data for R3 live and for play-it-again items. These work in VLC - but that does not support exclusive WASAPI. Foobar2000 claims to support DASH and works with WASAPI, but entering a BBC .mpd address that works in VLC causes foobar2000 to say it does not understand the format. Best quality on play-it-again without a Squeezebox setup seems difficult.

[Dave2002]

The other thing that is now obvious to me, but I failed to realise it previously, is that there is a re-sampling audio mixer within Chrome (and every other browser.) The single audio output from the browser has the audio from all players running within it. I think it has a fixed 48kHz 16bit output in Chrome, regardless of the output of the player running inside it or the Windows output setting. So after the AAC audio is decoded, it is re-sampled twice before it gets to the DAC, and the re-sampling in Chrome is possibly truncated to 16 bit precision although the Windows mixer runs at 24 bit precision. I found some discussion about changing the mixer in Chrome to pick up the Windows settings but I think they did not get round to doing it.

There is no possibility of getting clean not re-sampled audio out of any browser. It would have to be coded so it could only run one audio player at once.

I can find the link address to the DASH .mpd data for R3 live and for play-it-again items. These work in VLC - but that does not support exclusive WASAPI. Foobar2000 claims to support DASH and works with WASAPI, but entering a BBC .mpd address that works in VLC causes foobar2000 to say it does not understand the format. Best quality on play-it-again without a Squeezebox setup seems difficult.

That’s very interesting. Well - at least slightly so. Presumably similar constraints apply to Mac browsers.

The implication is that playing any audio within a browser on any system (probably) is going to be limited quality wise compared with using player software specifically designed to overcome some of the limitations imposed by the respective systems. For some people the quality may still be good enough, while for others the shortcomings may be noticeable and objectionable to them.

You seem to think/believe that Squeezebox software avoids some of these problems. It may - I just don’t know.

Presumably some of the systems such as Audirvana also attempt to control/mitigate any such issues.

I don’t know whether VLC or Foobar also avoid some of these things.

[cmr_for3]

Back to the --enable-exclusive-audio feature in Chrome.

I realise I shared a lack of understanding with ShrikeT in the Head-Fi thread. Looking through some of the issues on the Chromium development site, it looks as if the main thing they were trying to achieve with the feature was not exclusive mode as understood by foobar2000 or JRiver which can avoid re-sampling by the Windows mixer. They wanted to use WASAPI to reduce latency, probably to improve lip-sync with video. If that is the case, it is not surprising that it does not switch the audio device into exclusive mode.

The other thing that is now obvious to me, but I failed to realise it previously, is that there is a re-sampling audio mixer within Chrome (and every other browser.) The single audio output from the browser has the audio from all players running within it. I think it has a fixed 48kHz 16bit output in Chrome, regardless of the output of the player running inside it or the Windows output setting. So after the AAC audio is decoded, it is re-sampled twice before it gets to the DAC, and the re-sampling in Chrome is possibly truncated to 16 bit precision although the Windows mixer runs at 24 bit precision. I found some discussion about changing the mixer in Chrome to pick up the Windows settings but I think they did not get round to doing it.

There is no possibility of getting clean not re-sampled audio out of any browser. It would have to be coded so it could only run one audio player at once.

I can find the link address to the DASH .mpd data for R3 live and for play-it-again items. These work in VLC - but that does not support exclusive WASAPI. Foobar2000 claims to support DASH and works with WASAPI, but entering a BBC .mpd address that works in VLC causes foobar2000 to say it does not understand the format. Best quality on play-it-again without a Squeezebox setup seems difficult.

That's a really useful post, an education! - obvious once you think about it but I had not. am I allowed to mention some open source software that is good for downloading easily from the BBC (and a 100 other sites?) it's replaced another slightly better known bit of software for me. I could test it's ability to capture the HQ programmes...

[johnb]

You seem to think/believe that Squeezebox software avoids some of these problems. It may - I just don’t know.

The LMS/Squeezebox system, with the iPlayer plugin, inherently avoids these issues by the very nature of how LMS/Squeezebox operates.

[Beresford]

Back to the --enable-exclusive-audio feature in Chrome.

There is no possibility of getting clean not re-sampled audio out of any browser. It would have to be coded so it could only run one audio player at once.

This blog from 2016 seems to indicate that in Chrome the resampler can be disabled. Any comment?

https://www.addictivetips.com/web/how-to-get-chrome-to-play-audio-in-surround-sound-fix/

I know that Chrome, unlike most other browsers, opens a separate Instance(?) for each tab, so that unresampled audio may be available in each tab.
I usually use Vivaldi for Listen Again, although I have found that sometimes Edge sounds slightly better.