Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[d_pert]

For the second time in a year I've had to reacquire about 1,500 24-bit* files in their original FLAC format and reconvert them to ALAC using a 3rd party conversion tool because 24-bit ALAC conversions I had created with MC25/26 (straight conversion, no DSP) were encoded at a much higher volume than the original source FLAC, hard coding occasional clipping 'tick' sounds during peak passages into some of the files.

Basis for claim:
--If I compare MC's audio analysis results of source FLACs where the average R128 L/R peak might be around -5dB, the resulting ALAC conversion in MC produces files which typically analyze higher than 0dB, e.g., around +3dB.
--If I compare MC's audio analysis results of ALACs produced from the same source FLACs using 3rd party tools, the analysis numbers are either identical or occasionally only very slightly different.
--If I watch the DSP Studio peak level percentage readout while playing the ALACs produced by MC (no DSP/normalization), peak passages often hit and stop at 100%; it's during those periods that I can hear the characteristic clipping-related 'ticks'; the original source FLACs and ALACs produced by 3rd party tools do not, or virtually never, hit 100%.
--I can play all three test files in any other player application; the same locations in the MC-produced ALACs exhibit the 'occasional clipping ticks' whereas the 3rd party-produced ALACs do not.
So, the clipping is definitely being hard coded into the files by MC.
--A simple listening test -- all other things the same -- also demonstrates that the MC-produced ALACs sound 'louder'.
--Playback tests can be at any reasonable actual/acoustic volume; distortion heard is not a byproduct of playback equipment.)

*I also have many tens of thousands of 16-bit files which were once FLAC, and which I once converted to ALAC with MC. Many of those show substantially greater than 0dB (e.g., > +4dB) in the R128 peak results. However, I have not ever noticed the 'clipping tick' sounds occurring in the 16-bit to 16bit conversions. I've hunted for it in such files, playing through peak solo piano passages which would definitely exhibit the artifact. So, perhaps this problem only arises with 24 bit files? Something to do with the larger dynamic range of 24 bit?

Try it yourself:
1) Get a fresh 24-bit FLAC, not produced by MC.
2) Convert it to ALAC with MC (use no DSP/normalization).
3) Convert it to ALAC separately with any other tool, without any DSP/normalization turned on (e.g. dBpoweramp, EZ-CD).
4) Compare both ALACs using any player, without any DSP/normalization turned on.
-->The MC-produced ALAC will sound louder.
5) Compare the audio analysis results of all three in MC.
-->The MC-produced ALAC will show substantially higher peak level numbers whereas the other will not.

This is a restatement and update of a similar call to attention which I posted in the MC25 forum a while back, here:
https://yabb.jriver.com/interact/index.php/topic,120734.msg834765.html#msg834765

[JimH]

There are many ways you can get a click in a file.  Take a look at Weird Problems (in my signature) for ideas.

[d_pert]

Hi JimH:

Thank you for this, however...

The 'ticks' I'm describing are a symptom of clipping in the files. The 'ticks' come in little storms which coincide exactly with max. peak levels. MC is raising the level during 24-bit FLAC to ALAC conversion, and clipping is being introduced.

Addressing the root of the problem: Why is MC raising the level during this kind of conversion, whereas other tools are not?

I agree that there are many, many ways to get 'ticks' during playback of digital audio, especially due to hardware conditions (buffers, hardware, cabling, etc.). I've chased elusive 'ticks' in DAWs since the '90s. It's a tired topic.

Thanks again.

[RD James]

I can't reproduce this.
When converting 24-bit FLAC to ALAC in Media Center, dBpoweramp's Audio CRC analysis produces identical results for the FLAC and ALAC tracks.

One thing to keep in mind is that Media Center will apply dither on audio format conversions even if there is no DSP applied, which means that having TPDF dither selected will modify the audio - though it should be in a completely inaudible manner and not cause any of the problems you describe.
Mostly, it means a little bit of extra noise in the lower two bits and a change in the checksum.
 
I suspect you must accidentally be applying some kind of DSP during the conversion. Or there is a bug which is doing so.

[d_pert]

Hi RD James:

(See also attached JPEG screencaps.)

I just did the following...

1. Acquired a fresh 24 bit 96kHz FLAC.
2. Converted it to ALAC using dBpoweramp 16.6.
3. Converted it to ALAC using MC 26.0.19 with "Apply DSP unchecked, Bitdepth=Auto, "Use Sox for resampling" checked in Options > Audio.
4. Converted it to ALAC using MC 26.0.19 with "Apply DSP unchecked, Bitdepth=Auto, "Use Sox for resampling" unchecked in Options > Audio.
Note: I know that Sox should have nothing to do with this conversion 'cause there's no resampling.

See picture attachment: Conversion Settings.jpg

I didn't need to CRC check them because I can see from the file properties of all three ALACs that they're slightly different file sizes.

Using dBpoweramp's ID-tag viewer: there are some different metadata fields in the ALAC produced by MC. The dBpoweramp ALAC has the exact same fields and metadata as the original FLAC. I'm wondering how you got the same CRC result, given that MC appears to automatically write different/extra metadata fields? Did you strip all tags out of both files before running the CRC compare? And even then, what are the chances that that would produce an identical CRC hash?

Also ... it's very interesting that the two FLACs made with JRMC26 are different, given that the Sox re-sampling option should have no relevance. (Huh?!)

Finally, on the level-raising point: I ran MC audio analysis on all four source FLAC and 3 ALACs). As expected, the MC-produced ALACs are averaging approx. 3dB higher peak levels. Also interesting that they're 0dB across the board (dbTP/L/R) whereas the original FLAC and the dBpoweramp ALAC both show the usual slightly different peak levels, and they're both the same three values.

Please see image attachment for the audio analysis results: All 4 files in MC Playing Now list.jpg

See also the four attachments for a side-by-side comparison of all four files:
4 x Properties - General.jpg
4 x Properties - Audio Properties.jpg
4 x Properties - ID-tag 1.jpg
4 x Properties - ID-tag 2.jpg

[d_pert]

So, simple review/summary:

The above is why I can't use MC to convert 24-bit FLAC to ALAC.

As the picture attachments demonstrate: with no DSP engaged at all, MC still applies some kind of gain boost during the conversion which drives some of the files, some of the time, into audible clipping.

[d_pert]

Hi again RD James:

I see now that you wrote "Audio CRC" ... that explains how you were able to isolate just the audio portion of the files.

And yes, I understand how differences in dithering would result in changes in file size when compression is involved.

I'll do an Audio CRC compare and post again if any relevant turns up.

However, this still does not get at why the apparent gain boost.

Thanks.

[RD James]

Well, something is obviously going wrong if the files are producing different results on analysis.
Seeing as they all read 0 dB though… you are re-running analysis on the newly converted files, right?

You need to use dBpoweramp's "Calculate Audio CRC" tool to compare audio for bit-exactness as well, not just file size (install the codec and run a "conversion" on the file using it to calculate the CRC).
Writing to another file format or even editing tags can change the file size due to the container - even if the audio itself is untouched.
I tried with a 24/96 track this time (I used 24/44.1 before) and get the same results: Media Center's ALAC conversion is identical to the source FLAC.

[d_pert]

CRC32      Filename

3BEF8214   D:\Desktop\Original FLAC.flac
693C61C4   D:\Desktop\JRMS wo Sox.m4a
B9BF3DE4   D:\Desktop\JRMS w Sox.m4a
3BEF8214   D:\Desktop\dB Poweramp.m4a

[RD James]

If you enable DSP in the conversion settings, are there any plug-ins enabled there? Maybe something is still being applied even though DSP should be disabled for conversion.
Make sure that dither is disabled too (general MC settings, not conversion options).
 
It might be useful if you upload the source track somewhere too.

[d_pert]

Thanks. To your earlier question: "you are re-running analysis on the newly converted files, right?

Answer: Yes. Actually, none of the files had been subjected to analysis until after all conversions were performed.

[d_pert]

With MC's Options > Audio > Advanced > Dither mode = No dithering, and all checkboxes in Options > Audio > DSP & output format (a.k.a. DSP Studio) unchecked:

CRC32      Filename

3BEF8214   D:\Desktop\Original FLAC.flac
54ABF6A9   D:\Desktop\Original FLAC.m4a

Also see attached audio analysis results/compare in MC image:

2 files in MC Playing Now list.jpg

[d_pert]

Files from latest test:

https://app.box.com/s/svk6b9j7dnt76xgda7wuvcnvxdszokwd

https://app.box.com/s/1yty0666whynssujw79497g9ut5ym93k

BTW -- You can hear the 'little storm of ticks' coinciding with peak(s) at approx. 30 seconds +/- in the MC-produced .m4a (ALAC). Not in the .flac.

[RD James]

Well there's definitely something going wrong, because my conversion here is completely untouched. CRC is a perfect match after Media Center's conversion to ALAC.

[RoderickGI]

In the "Audio Conversion Options", are you both settings "Bitdepth (if supported by encoder)" to "Automatic"?

d_pert, run your test again with the Bitdepth set to the same as the original, 24 Bit.

[d_pert]

Hi and thanks.

By clicking Options located under the Convert button: Audio Conversion Options > Bitdepth (if supported by encoder) = Automatic. Yes.

The other location which I think you mean when you say "both", the Encoder Settings, isn't available with the ALAC encoder. For years I've noticed the same behavior: it shows a small message "The current encoder is not configurable". I think that's just a normal/understood limitation.

When I convert 24-bit source files with the settings as described above (Automatic bitdepth), the output files are also 24-bit. Are you suggesting I re-run tests, setting it to 24-bit manually?

Also, just to recall from above: Many thousands of my 16-bit FLAC-to-ALAC converts are also showing >+3db peaks, so chasing bitdepth may be a red herring. However, I've never heard audible clipping in those (abnormally hot?) 16-bit files -- only in the 24-bit cases -- so that's why I've been focusing on 24-bit.

[d_pert]

Also, to my side-point in my first response to RD James:

"...it's very interesting that the two FLACs made with JRMC26 are different, given that the Sox re-sampling option should have no relevance."

Here are the Audio CRC results, comparing two ALACs output from FLAC source by MC, the only difference being Sox is engaged in Options -- which should have no relevance because no resampling is involved:

CRC
693C61C4   D:\Desktop\MC Test Files\JRMS wo Sox.m4a
B9BF3DE4   D:\Desktop\MC Test Files\JRMS w Sox.m4a

What could possibly explain that?

[d_pert]

Hi JimH:

I went through all the 'Weird and Wonderful' thread. None of the previously dealt-with issues recorded there seem relevant. Most deal with issues introduced at playback. In contrast: my issues are encoded in the files. The files measure hotter in level than source, and have Audio CRC differences (see reports above).

There is one 2008 article about Windows Home Server having produced file corruption, and earlier articles about hardware-related data large file corruption (bit-flipping, etc.). However, if I had a hardware-related problem, I assume the problem would present in other applications. The gain increase only happens with my MC, not with dBpoweramp or EZ-CD Audio Converter; the ALACs those produce are Audio CRC-identical to the source FLACs.

I believe I've also eliminated "user" causes: all DSP chain features are disabled. It should be just a straight lossless FLAC-to-ALAC convert.

Do you have any other ideas why this is happening to me, and not, e.g., RD James (see above) who generously ran tests and found his MC to be producing ALACs Audio CRC-identical to the source FLACs?

BTW, in case these things matter:
--I run in Portable mode.
--I do not use any 3rd party antivirus software.
--The windows 10 1909 (latest) Windows Defender is set to ignore all related folders.

Thanks again.

[RD James]

I'd try a local install, and perhaps doing a full reset and starting fresh with MC.
Make sure you back up the library beforehand, so that you can restore it later.
 
It's not the file, and MC can do this conversion without changing the audio, so that's all I can think to try at this point.

[d_pert]

Hi RD James:

Thanks. I seem to recall having done what you suggest in my May 2019 round with the same issue, but I'll give it a go this time to see what it reveals. Will report back.

[RoderickGI]

The other location which I think you mean when you say "both"

I meant both you and RD James, since you are essentially running parallel tests. I wanted to confirm there was no difference in your settings.

Are you suggesting I re-run tests, setting it to 24-bit manually?

Yes. I have seen reports where using automatic Bitdepth has caused some issues. Again, setting it manually eliminates this one variable.


Still, it is strange that is works for RD James and not for you. Running in portable mode is an obvious difference to eliminate.

[d_pert]

Well I've made progress.

I made stock/defaults fresh installs on the same PC I've been using throughout this thread -- both a Normal and a Portable fresh install:

Both produce 24 bit ALACs which match their FLAC sources perfectly (per Audio CRC compare). 

I've probed and probed my 'regular' Portable install's settings. I've turned everything relevant off and/or returned everything to defaults/stock settings, in every conceivably related quarter. No stone has been left unturned. Still ... that installation is producing 'hot' (high gain) clipped file conversions.

JRiver -- do you guys want to look at an INI file, or can I export a debug file or something?

[d_pert]

And...

--I restored my 'regular' Portable install (one with all my accumulated Settings and library)
--I backed up that 'regular' library and Settings using the normal MC library backup function
--I cleared the install folder and laid down a fresh install
--I launched that fresh install and restored the 'regular' library and Settings
--I ran another FLAC-to-ALAC conversion test
[drum roll...] Audio CRC shows FLAC and ALAC = identical.

So, it would appear that whatever is wrong with my MC is not contained in the Settings or the library.

Either there are 'other' settings -- not captured by the backup/restore -- or some kind of application corruption going on.

I can say that the user Settings have, over the years, been through many version upgrades, and have also had VSTs installed and uninstalled from the DSP studio. Perhaps the Settings became corrupted through those many upgrades, or there's a bug affecting how the DSP chain is read?

[d_pert]

Hi RoderickGI:

Sorry that I overlooked your post.

The fresh installs which are working both have bitdepth = Automatic. So that clears that.

As well, both the normal and Portable fresh installs, and both those with restored Settings/library are working fine. So that clears that.

I'm left with a mystery, though:

How and when did my long-time MC install became 'corrupted', especially in such a highly specific, narrow way: producing gain increases in file conversions. ?!?!? 

?

[RoderickGI]

It is a mystery. Sounds like it is fixed though.

I did think to ask about VSTs earlier, but as you had all DSP turned off, which would include VSTs, I didn't bother. I suspect one of the VSTs left something behind, or perhaps changed a standard MC DLL or something, and that was causing the issue.

I guess it doesn't' matter now, and there is no way to find out anyway. For future readers; try a full reinstall to fix such problems.

[d_pert]

Indeed. And compare audio analysis peak numbers of a converted file with its source after any major update to the software, or VST changes.

[d_pert]

Just FYI -- I grabbed all the .dlls from the Normal and fresh installation folder on C: and copied/overwrote them all into the problematic Portable install. Ran test again: problem still there.

[d_pert]

Whoa. I just started checking my (ostensibly) 'restored' Settings, and none of them carried through the Backup-Restore operation. The library database is all there, but all the application settings (many, many late nights) are not carried through. Am I looking at shooting approx. 100 images of the screen as I mine through dozens of MC screens to 'document' my Settings, and then surgically reconstruct them all manually? 

Could this be a Portable problem? Doesn't backup Settings? Thinks they're on C: or in the registry?

P.S. - Yes, I included "Settings" by checking the appropriate box during Restore.

[d_pert]

Back to isolating where the 'corruption' is, I also tried:

--replacing all the Portable sub-folders other than Application Data using the C: fresh ones, including \Plugins. Didn't fix the problem.
--replacing all the EXE files in the same manner
--replacing that Media Center 26.tbl file

No difference. Problem still there.

However ... When I delete User Settings.ini and let MC create a new/default one: the problem goes away.

So it would appear the 'issue' resides somewhere inside my User Settings.ini file.

Now to go inside the file... 

[d_pert]

I tried pulling sections out of the Settings.ini, anything that looked like it might be to do with the topic, one by one. No dice.

[RoderickGI]

Find an editor that can do a "diff" between the good and bad settings files, and see what shows up?

The bad one has to be pointing to an incorrect dll or DirectShow filter, or similar. At least, that is my first guess.

Weird that the Settings weren't restored, even though it is a Portable installation. Obviously a Portable installation isn't going to use the Registry.


But I haven't used a Portable install, so I am just guessing.

[d_pert]

I'm exhausted trying to tease out the elusive cause...

So I'm going to take photos of practically every GUI screen in MC and laboriously reconstruct my highly customized MC install on one PC.

Then, I guess I'll have to manually repeat all that on up to three (3) other PCs, because 'Backup' no longer includes Settings in Portable mode:

https://yabb.jriver.com/interact/index.php/topic,124075.0.html

Goodbye weekend(s). 

[RD James]

I don't know if there's a better alternative to copying the settings, but I think there is an option to run multiple instances of MC at the same time - so it would probably be a lot quicker to enable that and configure with the two windows side-by-side if you're doing it manually.
Once you have done this, it might be useful to compare the config files with a tool like WinMerge2011.

[d_pert]

Thanks RD James. Great idea. Must say: You have some nice tools up your sleeve.

Re: the duplication to other PCs: I could just let go of running Portable (which has some perks) and invest in the Normal install; because Normal still backs up with Settings I could then import both Library and Settings on the additional PCs if I also revert those to using thier Normal installs. Pain, though: all this is simply due to Settings having been mysteriously dropped from Portable Backup, sometime after initial release of MC26. (And ... I'm getting a feeling this point is currently misunderstood.  ?)

Other thing is, I was wanting to try Backup from my existing Portable (with the inexplicable gain increase conversion problem), and then Restore into the same Portable install, or a fresh one -- and see if that 'washes out' the phenomenon. Anyhooo.

[d_pert]

BTW -- I did bracket down the issue to the User Settings.ini file, specifically under one of the subheadings [Properties] or [Properties/...]. However, as I started removing those individual subsections, it lost consistency: the problem came and went with apparently no logic. So at that 'testing' level, it becomes a moving target. Hence the exhaution.

If anyone knows which particular line item(s) under those subheadings might be the culprit, please speak up. 

[RoderickGI]

(And ... I'm getting a feeling this point is currently misunderstood.  ?)

Nah, I think RD and I understand, and probably Jim if he read this far.

Settings backup for a portable install is broken. It needs a fix. When that might get down, who knows.

[d_pert]

Yippee!

https://yabb.jriver.com/interact/index.php/topic,124075.0.html

[d_pert]

Added observations:

I replicated the 'clipping during conversion' (and failed Audio CRC compare test) problem on two other PCs at home -- using thier exiting Portable installs.

The additional PCs inherited thier Settings -- at some stage -- from the same 'master' PC; I used Backup and Restore (incl. Settings) in ver. 24 or 25, to 'distribute' a 'standardized' setup to 2-3 secondard PCs. All Portable installs were subsequently in-place upgraded to MC26.

This suggests that:

a) The 'issue' cannot be 'cleansed out' by backing up and restoring Settings.
b) Once affected, Settings which include 'the issue' will carry that issue to different PCs.

[d_pert]

Okay ... major discovery and update:

The problem had to do with left over old Zones from past configurations, in User Settings.ini.

What on earth any Zone settings have to do with Conversion, let alone causing Conversions to specifically increase gain to the point of clipping -- who can guess. This is some kind of obscure bug.

By simply removing any subheadings with the same Zone 'ID', *AND* which were Zones containing an old Name which I no longer use in my current configuration -- I was able to eliminate the gain-increase/clipping Conversion issue! Repeated and verified!

Zone-related sections appear in the following format in User Settings.ini:

[Zones\\10##]
[Zones\\10##\otherword]
[Zones\\100##]
[Zones\\100##\otherword]

Each set of subheadings containing the same \\10##\ or \\100##\ 'ID' contains, somewhere within, the name of the Zone, e.g.:

Player Zone Name="HDMI"

Just delete from User Settings.ini any subsections associated with old\defunct Zones.

Perhaps JRiver could:

a) prevent old vestigial Zones from influencing manual Conversions (?!)
b) remove/eliminate old vestigial Zones automatically so that a) becomes redundant

In the meantime, it appears that manually editing User Settings.ini as described above is the only way.

Extra Note:

My test logic, earlier, was frustrated and confused by an unrelated factor that was ALSO changing the Audio CRC such that any Audio CRC compare test would fail regardless of whether the difference was to do with the gain increase issue. If Audio > Advanced > Dithering is set to = TPDF, Audio CRC compare test will always fail (audio in files will be different). I believe this is to be expected as TPDF introduces some very slight, inaudible, changes to the audio as a byproduct. If Dithering is set to JRiver Bit-exact Dithering -- as the name implies -- Audio CRC compare tests will pass (audio in files will be identical). So, takeaway: If you're doing Audio CRC compare tests for some other reason, make sure your Dithering = JRiver Bit-exact Dithering (or 'No Dithering').

[RD James]

My test logic, earlier, was frustrated and confused by an unrelated factor that was ALSO changing the Audio CRC such that any Audio CRC compare test would fail regardless of whether the difference was to do with the gain increase issue. If Audio > Advanced > Dithering is set to = TPDF, Audio CRC compare test will always fail (audio in files will be different). I believe this is to be expected as TPDF introduces some very slight, inaudible, changes to the audio as a byproduct. If Dithering is set to JRiver Bit-exact Dithering -- as the name implies -- Audio CRC compare tests will pass (audio in files will be identical). So, takeaway: If you're doing Audio CRC compare tests for some other reason, make sure your Dithering = JRiver Bit-exact Dithering (or 'No Dithering').

I'd say that it's a bug, or an issue with the implementation of dither.
With the "bit-exact" dither, it doesn't do anything if there is no DSP (and applies insufficient RPDF dither if there is). So it was not something that had to be considered.
With TPDF it adds noise to the lower two bits. That's how TPDF works, but there's no need for it to be enabled if there is no DSP applied, as you would have with the conversion from one lossless format to another. You would have to dither when converting to lossy however.

[d_pert]

Understood. Thanks for that.

I also just realized that I may have accidentally blown away DSP presets only associated with Handheld Sync. I may have mis-ID'd them as "vestigial". Will backtrack and amend the post above if needed. 

[d_pert]

More:

So I narrowed it down even further...

I can eliminate the 'issue' simply by deleting one 'vestigial' Zone: [Zones\\1001\\...]

This is one of two which have only four numerical digits. Neither of those type seem to make reference to what we traditionally mean by Zones (named for output devices or listening locations). Those all have five numerical digits, e.g., \\10001\\. I think JRiver uses the 4-digit Zone 'ID's to store zone-like presets, like the Handheld Sync conversion settings.

I have one actual Handheld Device Sync conversion/DSP setting that I use. Inside User Settings.ini, there were two 4-digit Zones, \\1001\\ and \\1006\\. I deleted all parts of \\1001\\ because I thought it might be the 'earlier' / vestigial one and -- voilà! Main issue gone. Removing it did not impact my intended Handheld Sync Device conversion\DSP settings either.

So ... getting warmer ... the presence of what appears to be an 'earlier', defunct psuedo-Zone, most likely having existed for Handheld Sync purposes at some earlier date, relates to the main 'issue'.

Update: To refine the tips given in posts above: If you're cleaning up old/defunct Zones, stick to cleaning up the 5-digit ones. Then use trial-and-error on the 4-digit ones because ... one or more of those might actually support other zone-like settings elsewhere in MC (e.g., Handheld Sync DSP settings).

[d_pert]

I'm really just leaving this trail behind to help JRiver get to the root of the 'issue'.

I'm probably going to still do the side-by-side transfer of all settings into a 'fresh' Portable install. Peace of mind and all that. 

[d_pert]

Are positive, e.g., +1.2 dB, 'Peak Level' values in audio analysis results a bad thing?

Would any commercial studio-released file ever audio analyse with >0.0dB Peak Level values (R128, Sample)?

Under normal circumstances, and other than purposefully adding an excessive gain boost DSP during processing/conversion, why would a person ever see >0.0 dB Peak Level values in files?

Thank you.

[RoderickGI]

I have had, and think I still have, problems with left over Zones in the MC section of the Windows Registry. So I think you found the issue. I also don't know why that would have created your problem though... unless one of the funny old Zones was selected during the conversion, by ZoneSwitch or something, and invisibly. Zones are more than output devices, and have attached DSP and so on.

I believe that the five digit Zones are all Dynamic DLNA Zones, including those Zone seen on a MC Server while in a MC Client. i.e. "There" and "There: Remux Zone", which are the default player Zone on the Server, and one of my test Zones on the Server, respectively.

I currently have seventy (70) five digit Zones in the Registry on my Workstation where I do lots of testing. I only have one active Zone, the default "Player" Zone. These have just accumulated over time, and don't seem to get re-used much. Have a look at the attached image showing two separate Zones that are identical except for their number. I have lots of those.

I also have the default Player Zone, Zone 0, and three (3) four digit Zones, six (6) ten digit Zones, and a "Global" Zone. See the second image for a bit of proof.



I think there is a design problem here, or a bug, and I think it effects a few things, particularly DLNA discovery for some Dynamic Zones, and connectivity from some devices to a server. i.e. I still have an issue with Gizmo connecting to my Workstation Server, until I run Bingo SSDP, BubbleUPnP, or similar App which uses DLNA Discovery, and then Gizmo will connect. Gizmo connects to my HTPC Server first time, every time, without special treatment.

A fix would be nice.



Thanks for doing the hard work narrowing down this issue d_pert. I tied for a while, but doing it in the Registry, and deleting stuff from there for testing, was way too time consuming and risky!

[mattkhan]

It is called an inter sample peak and it is quite common. Fortunately MC will adjust for this automatically if you let it.

[RD James]

If you use a tool that maximizes the volume based on its samples; i.e. the audio data, you can have 0 dB peaks that don't appear to have clipping.
But samples are not waveforms, and the waveform resulting from 0 dB samples can end up clipped. These are called inter-sample peaks and are what the "Peak Level (R128)" tag displays.



The fortunate thing is that if there is no clipping in the samples, you can simply play back the audio at a lower volume level to avoid the inter-sample clipping - which is what Media Center does when Volume Leveling or Adaptive Volume (peak level normalize) are enabled.
 
Clipping can also a problem for conversion from lossless to lossy audio formats.

[d_pert]

Okay great (thanks for the great explanation). I can now imagine -- correct me if I'm wrong -- that a file mastered and intended to peak at <0.0dB might 'accidentally' (?) creap slightly above 0 in MC's Audio Analysis due to the inter-sample effect.

However, I've got lots of MC Audio Analysis results ranging up to +5.8dB.

Next question: Is there a theoretical maximum increase that can be attributed to the inter-sample effect? I would think it would always be extremely small. Can the inter-sample effect possibly produce +3, +4, +5 dB values, which I periodically see in my MC Audio Analysis results?

[mattkhan]

I think one can synthesise a signal that goes above 10dB but something is v wrong if that happens in real content which will typically be <1 but may go upto 4-5 with a small number of (presumably badly mixed) tracks.

[Hendrik]

Can the inter-sample effect possibly produce +3, +4, +5 dB values, which I periodically see in my MC Audio Analysis results?

No, it should not go this high. Its generally at most 1dB.

What can happen besides that however is that a float-based lossy audio decoder produces samples that exceed the -1.0 to 1.0 range, and because its a floating point decoder it won't natively clip. An integer-based decoder (as every lossless format uses) wouldn't even have that option, since it cannot possibly exceed its maximum value - there is just no more bits.