INTERACT FORUM
More => Old Versions => JRiver Media Center 26 for Windows => Topic started by: d_pert on February 03, 2020, 05:37:09 pm
-
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
-
There are many ways you can get a click in a file. Take a look at Weird Problems (in my signature) for ideas.
-
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.
-
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.
-
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
-
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.
-
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.
-
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 (https://www.dbpoweramp.com/codec-central-utility.htm) 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.
-
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
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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). :P
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?
-
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?
-
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. ?!?!?
:P ?
-
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.
-
Indeed. And compare audio analysis peak numbers of a converted file with its source after any major update to the software, or VST changes.
-
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.
-
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.
-
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... :-\
-
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.
-
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.
-
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). :'(
-
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 (https://bitbucket.org/jtuc/winmerge2011/downloads/WinMerge_0.2011.007.444_x64_change_7z_to_exe_if_you_want_a_setup.7z).
-
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.
-
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. :D
-
(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.
-
Yippee!
https://yabb.jriver.com/interact/index.php/topic,124075.0.html
-
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.
-
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').
-
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.
-
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. ::)
-
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).
-
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. ;)
-
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.
-
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!
-
It is called an inter sample peak and it is quite common. Fortunately MC will adjust for this automatically if you let it.
-
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.
(https://abload.de/img/loudness-09-yhmwrca2mv6j4s.jpg)
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.
-
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?
-
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.
-
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.
-
P.S. -- I'm trying to assess the significance and extent of an unexplained gain increase that was introduced into many of my files during FLAC->ALAC conversion using MC. That 'issue' involved audible clipping during peak passages -- hard coded into the files -- and is being explored separately here:
https://yabb.jriver.com/interact/index.php/topic,124054.0.html
I'm trying to assess how many of my files -- going how far back -- were affected by that 'issue'.
Part of this assessment is determining whether 'high' e.g., +3dB Audio Analysis results are fundamentally a sign of abnormality, and whether such values are likely to be only a product of the above-noted 'issue'.
If, however, it's normal/natural for such values to turn up in MC's Audio Analysis for other reasons -- using any files acquired new / in the wild -- due to, e.g., inter-sample effects -- then I will avoid making a logical leap that any such files were negatively impacted by the 'issue'.
I'll have to come up with some other logic for narrowing down to the affected files.
I'm both hoping and not hoping that large + values in Audio Analysis are linked to the above-noted 'issue'. If they are, then I've got a lot more files to reacquire and reconvert. If they're not, then the number of damaged files should theoretically be smaller (whew!), but it'll be hard to ID those... ::)
-
There's yet more narrowing and refinement to be had...
Some of those 'vestigial' (or, just unknown history/purpose) Zones I deleted are re-created by MC upon next launch.
The one Zone which was by itself 'causing' (so to speak) the gain increase issue -- and which I deleted -- was:
============================================================
[Zones\\1001\\Adaptive Volume]
Enabled=i:"1"
[Zones\\1001\\Audio Settings]
Allow Custom Output Format=i:"1"
Last Change Time=i:"1412281191"
Output Channels=i:"2"
Output Encoding=i:"0"
Output Padding Channels=i:"0"
Output Pseudo Surround Detection=i:"1"
Output Sample Rate Settings="(1:3)(1:0)(1:0)(1:0)(5:44100)(5:48000)(5:44100)(5:48000)(5:44100)(5:48000)(5:44100)(5:48000)(5:44100)"
Output Surround Mode=i:"1"
Output Surround Phantom Center=i:"0"
Output Surround Subwoofer Cutoff=i:"60"
Output Surround Subwoofer Cutoff Downmix=i:"120"
Output Surround Subwoofer Impact Filter=i:"1"
Output Surround Two Point One Mixing=i:"0"
Overflow Handling Mode=i:"1"
[Zones\\1001\\DSP Studio]
DSP Studio Last Selection="TB_Isone_v3"
Plugin Order="(1:1)(2:13)(13:Output Format)(15:Volume Leveling)(15:Adaptive Volume)(9:Equalizer)(20:Parametric Equalizer)(7:Effects)(10:Headphones)(11:TB_Isone_v3)(13:Tempo & Pitch)(15:Room Correction)(11:Convolution)(22:Parametric Equalizer 2)(8:Analyzer)"
Plugin Order Version=i:"5"
[Zones\\1001\\Headphones]
Crossfeed (Cutoff Frequency)="700"
Crossfeed (Delay MS)="0.26"
Crossfeed (Stregth)="0.5"
Enabled=i:"0"
[Zones\\1001\\jb_broadcast]
Enabled=i:"1"
Last Program Data="<XMLPH version\=\"1.0\">\r\n<Item Name\=\"10\">0.2000000029802322</Item>\r\n<Item Name\=\"11\">0.1500000059604645</Item>\r\n<Item Name\=\"12\">0.1500000059604645</Item>\r\n<Item Name\=\"13\">0.1500000059604645</Item>\r\n<Item Name\=\"20\">1</Item>\r\n<Item Name\=\"14\">0.300000011920929</Item>\r\n<Item Name\=\"21\">0</Item>\r\n<Item Name\=\"15\">0.300000011920929</Item>\r\n<Item Name\=\"22\">0.1000000014901161</Item>\r\n<Item Name\=\"16\">0.6000000238418579</Item>\r\n<Item Name\=\"23\">0.1000000014901161</Item>\r\n<Item Name\=\"17\">0.6000000238418579</Item>\r\n<Item Name\=\"24\">0.1000000014901161</Item>\r\n<Item Name\=\"0\">0.8365384340286255</Item>\r\n<Item Name\=\"18\">0.6000000238418579</Item>\r\n<Item Name\=\"25\">0</Item>\r\n<Item Name\=\"1\">0</Item>\r\n<Item Name\=\"19\">0</Item>\r\n<Item Name\=\"26\">1</Item>\r\n<Item Name\=\"2\">1</Item>\r\n<Item Name\=\"3\">1</Item>\r\n<Item Name\=\"4\">1</Item>\r\n<Item Name\=\"5\">0.699999988079071</Item>\r\n<Item Name\=\"6\">0.6000000238418579</Item>\r\n<Item Name\=\"7\">0.4000000059604645</Item>\r\n<Item Name\=\"8\">0.4000000059604645</Item>\r\n<Item Name\=\"9\">0.300000011920929</Item>\r\n</XMLPH>"
Last Program Index=i:"3"
[Zones\\1001\\SyncInfo]
DataConsumedLatency="371519"
[Zones\\1001\\TB_Isone_v3]
Enabled=i:"1"
Last Program Data="<XMLPH version\=\"1.0\">\r\n<Item Name\=\"10\">0.3333333432674408</Item>\r\n<Item Name\=\"11\">0</Item>\r\n<Item Name\=\"12\">0.6666666865348816</Item>\r\n<Item Name\=\"13\">0</Item>\r\n<Item Name\=\"20\">0.5</Item>\r\n<Item Name\=\"14\">0.5</Item>\r\n<Item Name\=\"21\">0.5</Item>\r\n<Item Name\=\"15\">0.4999999701976776</Item>\r\n<Item Name\=\"22\">1</Item>\r\n<Item Name\=\"16\">0.5</Item>\r\n<Item Name\=\"23\">0</Item>\r\n<Item Name\=\"17\">0.3499999940395355</Item>\r\n<Item Name\=\"24\">0</Item>\r\n<Item Name\=\"0\">0</Item>\r\n<Item Name\=\"18\">0.425000011920929</Item>\r\n<Item Name\=\"25\">0</Item>\r\n<Item Name\=\"1\">0</Item>\r\n<Item Name\=\"19\">1</Item>\r\n<Item Name\=\"2\">0</Item>\r\n<Item Name\=\"3\">0.0020184789318591</Item>\r\n<Item Name\=\"4\">0.75</Item>\r\n<Item Name\=\"5\">0.02203269302845</Item>\r\n<Item Name\=\"6\">0.75</Item>\r\n<Item Name\=\"7\">0.727078914642334</Item>\r\n<Item Name\=\"8\">0.75</Item>\r\n<Item Name\=\"9\">0</Item>\r\n</XMLPH>"
Last Program Index=i:"4"
[Zones\\1001\\TB_Isone_v3\\Presets]
DP01="<XMLPH version\=\"1.0\">\r\n<Item Name\=\"10\">0.3333333432674408</Item>\r\n<Item Name\=\"11\">0</Item>\r\n<Item Name\=\"12\">0.6666666865348816</Item>\r\n<Item Name\=\"13\">0</Item>\r\n<Item Name\=\"20\">0.6000000238418579</Item>\r\n<Item Name\=\"14\">0.5</Item>\r\n<Item Name\=\"21\">0.75</Item>\r\n<Item Name\=\"15\">0.4999999701976776</Item>\r\n<Item Name\=\"22\">1</Item>\r\n<Item Name\=\"16\">0.5</Item>\r\n<Item Name\=\"23\">0</Item>\r\n<Item Name\=\"17\">0.3499999940395355</Item>\r\n<Item Name\=\"24\">0</Item>\r\n<Item Name\=\"0\">0</Item>\r\n<Item Name\=\"18\">0.449999988079071</Item>\r\n<Item Name\=\"25\">0</Item>\r\n<Item Name\=\"1\">0</Item>\r\n<Item Name\=\"19\">0.8999999761581421</Item>\r\n<Item Name\=\"2\">0</Item>\r\n<Item Name\=\"3\">0.0020184789318591</Item>\r\n<Item Name\=\"4\">0.75</Item>\r\n<Item Name\=\"5\">0.02203269302845</Item>\r\n<Item Name\=\"6\">0.75</Item>\r\n<Item Name\=\"7\">0.727078914642334</Item>\r\n<Item Name\=\"8\">0.75</Item>\r\n<Item Name\=\"9\">0</Item>\r\n</XMLPH>"
[Zones\\1001\\Volume Leveling]
Enabled=i:"1"
============================================================
MC then (re)created the following -- much shorter -- and which did not reintroduce the 'issue':
============================================================
[Zones\\1001\\Audio Settings]
Allow Custom Output Format=i:"1"
Last Change Time=i:"1412281191"
Output Channels=i:"2"
Output Encoding=i:"0"
Output Padding Channels=i:"0"
Output Pseudo Surround Detection=i:"1"
Output Sample Rate Settings="(1:3)(1:0)(1:0)(1:0)(5:44100)(5:48000)(5:44100)(5:48000)(5:44100)(5:48000)(5:44100)(5:48000)(5:48000)"
Output Surround Mode=i:"1"
Output Surround Phantom Center=i:"0"
Output Surround Subwoofer Cutoff=i:"60"
Output Surround Subwoofer Cutoff Downmix=i:"120"
Output Surround Subwoofer Impact Filter=i:"1"
Output Surround Two Point One Mixing=i:"0"
[Zones\\1001\\DSP Studio]
DSP Studio Last Selection="Adaptive Volume"
Plugin Order="(1:1)(2:13)(13:Output Format)(15:Volume Leveling)(15:Adaptive Volume)(9:Equalizer)(20:Parametric Equalizer)(7:Effects)(10:Headphones)(13:Tempo & Pitch)(12:jb_broadcast)(15:Room Correction)(11:Convolution)(22:Parametric Equalizer 2)(8:Analyzer)"
Plugin Order Version=i:"5"
[Zones\\1001\\SyncInfo]
DataConsumedLatency="170666"
============================================================
I have a feeling this is a store of the default, or MRU (most recently used) DSP studio settings, for Conversion purposes. Just a theory.
Observations:
1) Even if the 'old' Zone 1001 posted above was corrupt, or had some unintended setting, it should have had no bearing on my Conversions because I verified all the settings visually. In every case of straight FLAC-to-ALAC conversion, including in all my tests referred to above, I've positively ensured that DSP is complete disengaged, etc. So ... it's like whatever in that 'old' Zone 1001 was causing the issue was asserting itself despite the apparent setting(s) in the GUI.
2) In the 'old' Zone 1001 -- which is much longer than the new one -- there is a reference to a VST plugin which is no longer even installed on any of my systems. Haven't used it in years: "jb_broadcast".
Update:
3) The following appears in the 'old' but not the 'new:
[Zones\\1001\\Volume Leveling]
Enabled=i:"1"
While this certainly catches the eye, it a) shouldn't have had any effect because DSP was unchecked/off throughout, and b) MC's Volume Leveling doesn't overdrive files into audible clipping (or certainly never does by design).
-
P.S. -- I'm trying to assess the significance and extent of an unexplained gain increase that was introduced into many of my files during FLAC->ALAC conversion using MC. That 'issue' involved audible clipping during peak passages -- hard coded into the files -- and is being explored separately here:
https://yabb.jriver.com/interact/index.php/topic,124054.0.html
I'm trying to assess how many of my files -- going how far back -- were affected by that 'issue'.
Part of this assessment is determining whether 'high' e.g., +3dB Audio Analysis results are fundamentally a sign of abnormality, and whether such values are likely to be only a product of the above-noted 'issue'.
If, however, it's normal/natural for such values to turn up in MC's Audio Analysis for other reasons -- using any files acquired new / in the wild -- due to, e.g., inter-sample effects -- then I will avoid making a logical leap that any such files were negatively impacted by the 'issue'.
I'll have to come up with some other logic for narrowing down to the affected files.
I'm both hoping and not hoping that large + values in Audio Analysis are linked to the above-noted 'issue'. If they are, then I've got a lot more files to reacquire and reconvert. If they're not, then the number of damaged files should theoretically be smaller (whew!), but it'll be hard to ID those... ::)
I would assume anything produced by those conversions to be bad, and likely driven to hard clipping; not just having inter-sample peaks.
-
I believe that the five digit Zones are all Dynamic DLNA Zones
user created zones are in that range also
-
More findings:
Please see the attached image.
It compares Audio Analysis of a source (master) ALAC and three different Conversions through Handheld Sync. All files are 24bit/48kHz.
With both Volume Leveling (VL) AND Adaptive Volume (AV) turned on (in the Handheld Sync DSP Settings), the resulting file is being driven to +0.0dB AND exhibits the hallmark audible artifacts of digital clipping (the little clusters of 'ticks' coinciding with peak passages).
However, with only VL or only AV engaged, the resulting files neither analyse as high as 0dB, nor exhibit clipping audibly.
In the earlier stages of this thread, all tests which produced 'over driven' files with the clipping sounds were converted with no DSP engaged at all (incl. no AV or VL). Deleting several seemingly obsolete Zones from User Settings.ini seemed to stop that from happening.
However, here, again, is virtually the same issue, cropping up in a different operation (Handheld Sync).
I'll try the same test set in Playing Now; maybe it has nothing to do with the Handheld Sync context...
P.S. -- I re-analysed the source (master) file before performing these tests, in case the existing measurements were somehow in error.
P.P.S. -- In all tests, Adaptive Volume = Peak Level Normalize mode, AND, "Clip protection" = ON always/universally.
-
Attached are the results of the same test set run in Playing Now instead of Handheld Sync.
The results are identical so it has nothing to do with the Handheld Sync context. Sorry if that was a red herring.
-
And finally, please see the attached image.
I repeated the last test, only the VL+AV combination in my NORMAL (not Portable) install, which is a completely factory-default configuration because I never use it.
The results are identical.
So it has nothing to do with Portable install, or old/uninstalled VSTs. And the relationship to old Zones is now unclear. It would seem to be native to the stock MC26.
-
So it looks like you have eliminated old Zones as the cause, but just to complete a thought if I may...
user created zones are in that range also
I don't have any User Created zones in the five digit range. I do see User Created Zones from the MC Server, on the MC Client PC. An example is the Server "Remux Zone", which is seen on the Client as "There: Remux Zone", with a five digit number.
I'll look into this separately, again, if I find time. Carry on! ;D
-
Except that deleting Zone \\1001\\, and letting MC create a smaller version of it DID eliminate the problem of MC boosting the gain in 'direct' Conversions (no DSP Studio, no VL, no AL).
This last set of tests only shows that the problem can be reintroduced temporarily by enabling the combination of VL+AL.
Easy to confuse apple with oranges with this stuff. :-\
-
If I recall correctly, Adaptive Volume doesn't work in fixed mode for conversions.
-
'Fixed mode'? Can you explain?
The tests I ran with AV (see images above) have distinct Audio Analysis results, implying that AV did something rather than nothing.
-
just downloaded your original FLAC file, converted to ALAC, and Analysed the converted file. Results as per image.
Looks good to me. As RD James found, identical to the original FLAC. There must be something about your environment that is different, in both the normal MC installation and the Portable install.
The Portable installation does use the normal installation as a source of the Registration information. Perhaps it uses more than that, and is the source of the issue on the Portable install?
Maybe because you have never used the normal installation, something hasn't completed correctly, such as components haven't been downloaded on demand when you play files? An old default ALAC Codec/converter perhaps? The PC is connected to the internet to download components, isn't it? It sounds like you should solve the problem on the normal installation first, and then the fix may transfer to a new Portable installation?
-
Did you apply AV and VL during the conversion?
I did eliminate the problem for straight conversions, by house-cleaning old Zones in User Settings.ini.
However, the problem re-surfaces when conversion includes DSP Studio: Adaptive Volume AND Volume Leveling together.
This thread spanned two (2) phases -- sorry if the transition isn't clear:
phase 1) gain boost / clipping problem in DSP-free lossless-lossless 24bit conversions (workaround by deleting old Zones, etc.)
phase 2) gain boost / clipping problem in DSP: (AV+VL) lossless-lossless 24bit conversions (no workaround yet apparent)
I just went to another PC (DAW setup -- very lean and mean) and fired up a virgin install of MC26:
Same problem again: Lossless-to-lossless FLAC-to-WAV 24 bit conversion with DSP Studio AV+VL: files 'driven' up to +0.0dB, audible clipping.
-
Did you apply AV and VL during the conversion?
Nope. I don't ever add DSP of any sort to conversions. I might be forced to for Handheld Sync at some time, but so far haven't. So...
phase 2) gain boost / clipping problem in DSP: (AV+VL) lossless-lossless 24bit conversions (no workaround yet apparent)
I'm not buying in to Phase 2. ;)
Oh okay, just for giggles. See image.
-
Thanks for this.
Indeed: One would not normally apply DSP in conversions. Me either. ;) I just discovered the 'overboost' into clipping because I happen to use it for Handheld Sync. Taking it over to normal Playing Now-type conversions was just to show that it was not a phenomenon limited to Handheld Sync.
Anyway ... So there's the +0.0dB across the board.
Is it a track where you can easily distinguish the clipping during peak passages (like, piano)?
-
'Fixed mode'? Can you explain?
The tests I ran with AV (see images above) have distinct Audio Analysis results, implying that AV did something rather than nothing.
There is "fixed mode" which uses the audio analysis data to make a fixed adjustment with peak level normalization selected. All this does is boost the volume by a fixed amount.
There is also "adaptive mode" which is applied to tracks with no analysis data, and I believe it's also used for conversions. This can result in clipping since it's an adaptive dynamic range compression rather than a fixed volume offset.
-
Hmm. Not sure about parts of that. The JRiver literature online seems pretty clear: AV (Peak level normalize) mode, and VL together net to a simple gain adjustment, no compressor/limiter style DSP there. And anyway, with the math all correct and Clip Protection added to the design, there shouldn’t ever be audible clipping introduced.
I’m so glad RoderickGI’s image indicates what I’m describing.
Other mystery is: why would all channels on a randomly selected acoustic track measure with the same exact same peak level unless the real peaks had been driven ‘through the top’? The source track shows different peaks per channel. Update: I realize that last thought is flawed and withdraw it. :-X The R/L peaks could be from different parts of the file.
-
Hmm. Not sure about parts of that. The JRiver literature online seems pretty clear: AV (Peak level normalize) mode, and VL together net to a simple gain adjustment, no compressor/limiter style DSP there. And anyway, with the math all correct and Clip Protection added to the design, there shouldn’t ever be audible clipping introduced.
That is for playback, I believe conversion is handled differently.
Volume Leveling + Adaptive Volume received significant updates a few years back to implement R128 support, but many of the changes only apply to playback.
-
Interesting. Well anyway: it’s still an issue that would need addressing. It should be all but impossible to introduce audible clipping into conversions simply by using innocuous normalization features.
-
Is it a track where you can easily distinguish the clipping during peak passages (like, piano)?
It's just the track you linked to earlier in the thread. I hadn't even listened to it until now. Nice track.
Unfortunately I'm not at my good sound system at the moment. Just my Workstation with rubbish speakers, and listening with my rubbish ears which sometimes add resonance anyway.
I normally play music with Internal Volume set at 80%, and have MC set System Volume at 100%, which only leaves the analogue volume of the powered speakers with volume control. I cranked the Internal Volume up to 100% to see what I could hear. The early part of that track is the loudest, visibly hitting 86% Peak Volume in the DSP Studio Analyzer. Well, I can't tell if it is clipping. Some of the louder notes of the horns aren't pure, but I can't hear any ticks, pops, crackles, or anything else. So, probably no clipping. But I'm no expert.
-
Cool and thanks. There’re are a few places in the opening horn(s) section; maybe tomorrow I can send you time-codes so you can A/B compare. Short, passing episodes of little static ticks on some peaks. None in the source.
-
Cool and thanks. There’re are a few places in the opening horn(s) section; maybe tomorrow I can send you time-codes so you can A/B compare. Short, passing episodes of little static ticks on some peaks. None in the source.
Please take a look at some of the many causes of sound problems listed in this thread:
https://yabb.jriver.com/interact/index.php/topic,24031.0.html
-
Hi JimH:
Thanks, but again, nothing in Weird and Wonderful can be applied to this topic.
The images attached above (from me and RoderickGI) plainly show that under certain circumstances, converted files are being excessively boosted.
Short Review
--24-bit lossless-to-lossless Conversions were cranking the gain of output files. Fulsome description and pictorial evidence of this above. Fresh installs, Fresh MCs. Multiple PCs. 'Ticks' were not the issue -- only a symptom. This has not been about 'ticks'. In the end, I was only able to stop it by hacking User Settings.ini (removing Zones).
--Then a separate issue: 24-bit lossless-to-lossless Conversion using Volume Leveling *AND* Adaptive Volume *AND* "Clip Protection" are producing 'overdriven' files (see pictures attached above). These files flatline at +0.0dB on all channels and also exhibit baked-in audible digital clipping distortion coinciding exactly with peak passages.
Please:
--Take any 24 bit FLAC*.
--Audio Analyse it in MC 26.0.19-20.
--Queue it up for conversion in MC 26.0.19-20.
--Convert it to Uncompressed WAV, with DSP Studio: Volume Leveling *AND* Adaptive Volume (Peak Level Normalize mode) *AND* "Clip Protection" ENGAGED.
--Use MC's Audio Analyse on the outputted file.
--See the +0dB|+0dB|+0dB in Peak Level Field.
--Listen to the file on any device/platform: You'll hear occasional moments of digital clipping distortion on peak passages.
*Ideally pick music which does not include loads of distortion and digital noises/effects. E.g., simple pure piano.
-
I've uploaded a set of test/compare files to demonstrate/prove the issue. Fresh MC, normal install. Please download them here:
https://app.box.com/s/5wi9djhwsxunzclss9suxywv7mrkcknx
The audio files included are:
Test A - Original FLAC.flac
Test A - Straight to ALAC no DSP.m4a
Test A - Straight to ALAC w AV+VL+CP.m4a <--- listen to approx. 31s in.; compare with two above.
Test B - Original FLAC.flac
Test B - Straight to ALAC no DSP.m4a
Test B - Straight to ALAC w AV+VL+CP.m4a <--- listen to approx. 16s, and 54-55s; compare with FLAC above.*
Please also see the screencap of MC's Audio Analysis of all six files: '_Test A+B Analysis Screencap.png', attached to this post and also in the payload linked above.
*-Re: 'Test B - Straight to ALAC no DSP.m4a':
I performed test A then test B (in that order).
Bizarrely, this file, although only a no-DSP straight Convert, also exhibits the gain boost and audible distortion as 'Test B - Straight to ALAC w AV+VL+CP.m4a'.
The only reason I can think of that happening is ... to prepare Conversion for 'Test A - Straight to ALAC w AV+VL+CP.m4a', I entered the DSP Studio part of the Convert options and engaged AV+VL, as the filename indicates.
Then, when I prepared to produce 'Test B - Straight to ALAC no DSP.m4a', I did as that filename tells, and turned OFF 'Apply DSP...".
However, that didn't work; It's as if there's a bug in the ON/OFF switch(es) for DSP in Conversion Options. ?
-
(Crickets chirping.)
-
Lives living.
I'm a bit busy. Bump at the end of the week.
-
Update:
Well I took the plunge...
- Installed a fresh Portable MC 26
- Manually reconfigured (from scratch) the entire application
All the weirdnesses described in the OP and the thread above went away.
Although this is not a solution, others who may experience similar annomolies can perhaps take solace in knowing that "start from scratch" ultimately cleared the issue for this user. ::)
P.S. -- It may be that the Settings.ini became confused over the years; I'd carried it through Backup and Restore operations through major version upgrades for years. Guess it was time to clean the slate.