my understanding of the situation is continuing to evolve. i've isolated the proper components, it's just a question of getting them in the right order.
the reinstall with the registry run removed eliminated all bleeding, but brought me back to the point where the highs are turning off and on. but, i've learned that this is not random, as i previously thought. rather, it's connected to the streaming proxy service - the broken clock.
when this service is launched, i get the full spectrum. when it's not, i get reduced highs. and, when it turns off [as it does], i get those annoying cut-outs.
but, the service doesn't launch through foobar - it only launches through cubase. again, this is explanatory, as i was noticing that cubase sounds differently than foobar. the service will sometimes stay on after i close cubase, at which point the foobar out will keep the highs - until it stops, when the highs drop. further, whether it launches with cubase or not is sporadic.
the firmware flash is no longer modifying the output, which indicates that the issue was in fact in the registry. but, it's also made it more difficult to get back to the sweet spot. the flash doesn't always work.
i strongly suspect that the point i'm at right now was the starting point; the sound is acceptable, and probably defines the differences i was noticing previously between the different hardware, and just thought was hardware dependent. it's relatively mild. but, now that i know it's not clean, i have to fix it.
the basic problem seems to be that the service is no longer connected to the devices.
but, i know that if i connect the service to the devices via the registry run on the install then i get fading.
i'm also noticing that the other card in the machine is maintaining consistency with the weak highs. in the past, i may have misinterpreted this - i may have taken the consistency as indicating both cards were working, and then concluded the output was solid, when in fact there seems to be a root problem that is affecting both cards.
there's two things i can try.
the first is that i can try a reinstall without breaking that first aspect of the clock. as mentioned before, it's only that first part that i'm certain i was reinstalling and only the first that windows is recognizing post-break. the other two, i'm just blurry about. i'll have to check to see what i get out of that - and i can do partial installs for this purpose.
if that creates the same basic issue, the next step is to put that part back in the registry run on the driver install.
if that brings me back to the bleeding, i can try and take out the entire clock break.
so, that means i'm now going beyond trying to get back to where i was and trying to fix a problem that was there the whole time but that i never noticed.
i don't think it will be much longer. i'm pretty sure i've got my head around this, now - i'm no longer taking guesses. the guesses have isolated the issue, and now i'm zeroing in on it.
Sunday, August 23, 2015
i tested the issue by flashing the device and leaving it on for a reboot. if it was a firmware corruption, it should have come up clean on the reboot - because the device stayed on. but, it didn't. so, it's an error that's happening when windows recognizes the device. and, because it's not happening on the flash, it has to be the result of some kind of corrupt registry setting - because everything else would be the same, whether it's rebooting itself on the flash or being read as a device by windows.
when i do the reinstall, i'm going to try and clean as much out of the registry as i can get out of it - and i do think i can probably get this to work. but the class installer uses long strings of numbers that are difficult to track down.
i can't explain why this wasn't happening previously - except that it maybe was, and i didn't notice. which is another layer to keep in mind as i'm reanalyzing material.
the other thing is that i have a vague recollection of deleting the filters on the install a while back. so, those filters might have been gone for quite a while. i can't clearly remember. that's something i can script, and should so i don't forget.
the driver reinstall helped substantially, but it still seems a little distorted, so i'm going to reinstall a final time - i feel i have to to be sure i've actually hit the root of the problem. but i think i'm starting to finally get my head around what actually happened.
1) i think i cleared out the registry on the last reinstall, some time ago - whenever it was. spring of 2014, maybe.
2) then at some point in may i put that file back (streamci.dll).
3) on a driver reinstall (these are done from time to time, to deal with funny plugins), that screwed up the registry.
4) when i deleted the clock before, it didn't matter - because i wasn't really using it for this device. but, the combination of the driver install and the undeletion of the clock created a conflict. i suspect i should be able to reinstall the clock after i stop the drivers from entering that information into the registry.
the root cause of all of this, then, seems to be the driver install with the streamci.dll in place. i suppose i may have exaggerated something with that codec install, but it wasn't the actual crux of the problem.
when i do the reinstall, i'm going to try and clean as much out of the registry as i can get out of it - and i do think i can probably get this to work. but the class installer uses long strings of numbers that are difficult to track down.
i can't explain why this wasn't happening previously - except that it maybe was, and i didn't notice. which is another layer to keep in mind as i'm reanalyzing material.
the other thing is that i have a vague recollection of deleting the filters on the install a while back. so, those filters might have been gone for quite a while. i can't clearly remember. that's something i can script, and should so i don't forget.
the driver reinstall helped substantially, but it still seems a little distorted, so i'm going to reinstall a final time - i feel i have to to be sure i've actually hit the root of the problem. but i think i'm starting to finally get my head around what actually happened.
1) i think i cleared out the registry on the last reinstall, some time ago - whenever it was. spring of 2014, maybe.
2) then at some point in may i put that file back (streamci.dll).
3) on a driver reinstall (these are done from time to time, to deal with funny plugins), that screwed up the registry.
4) when i deleted the clock before, it didn't matter - because i wasn't really using it for this device. but, the combination of the driver install and the undeletion of the clock created a conflict. i suspect i should be able to reinstall the clock after i stop the drivers from entering that information into the registry.
the root cause of all of this, then, seems to be the driver install with the streamci.dll in place. i suppose i may have exaggerated something with that codec install, but it wasn't the actual crux of the problem.
it's continuing to behave poorly, but it really has to be a registry issue. i'm going to try a driver reinstall, but if that doesn't work i'll have to back up and do it again - this time inserting a wipe before the reboot, to prevent the install from completing.
on a clean sweep install with everything the way it was saved a few weeks ago, which means that the streaming proxy bit & clock are broken, it no longer bleeds. it's stable on the out. but, the out is missing a layer at the high end. it sounds like less an eq dive and more like a straight low pass, but i'm suspecting it's more along the lines of that a part of the stream is broken. it's pretty high - around 10 Khz or so. and, if you'll recall, this was the basic problem i noticed in the first place, which had me mixing higher than i wanted.
but, here's an interesting fact: i've pointed out before that a firmware flash resolves the issue. and, that's what is continuing to happen, but only until i reboot the device. it's quite strange.
in theory, i could just flash the firmware every time i turn the device on. but, that's kind of scary. if the power goes out when it's flashing, i could brick the device. and, if the issue is that the firmware is instantly corrupting, i want to think about replacing it.
on a clean sweep install with everything the way it was saved a few weeks ago, which means that the streaming proxy bit & clock are broken, it no longer bleeds. it's stable on the out. but, the out is missing a layer at the high end. it sounds like less an eq dive and more like a straight low pass, but i'm suspecting it's more along the lines of that a part of the stream is broken. it's pretty high - around 10 Khz or so. and, if you'll recall, this was the basic problem i noticed in the first place, which had me mixing higher than i wanted.
but, here's an interesting fact: i've pointed out before that a firmware flash resolves the issue. and, that's what is continuing to happen, but only until i reboot the device. it's quite strange.
in theory, i could just flash the firmware every time i turn the device on. but, that's kind of scary. if the power goes out when it's flashing, i could brick the device. and, if the issue is that the firmware is instantly corrupting, i want to think about replacing it.
Saturday, August 22, 2015
this is a track i mixed with the highs faded out, and it sounds extremely tinny to compensate.
https://jasonparent.bandcamp.com/track/im-sure-your-mom-is-probably-a-very-nice-person
the exaggerated painfully tinny distortion is a consequence of having the volume cut at that frequency.
as mentioned previously: i'm absolutely certain that i've updated those streaming drivers before. and, when they're installed, the audio has a thicker sound that is preferable. but, it's the only thing left to test.
https://jasonparent.bandcamp.com/track/im-sure-your-mom-is-probably-a-very-nice-person
the exaggerated painfully tinny distortion is a consequence of having the volume cut at that frequency.
as mentioned previously: i'm absolutely certain that i've updated those streaming drivers before. and, when they're installed, the audio has a thicker sound that is preferable. but, it's the only thing left to test.
no. it ended up fading again...
i'm down to my last reinstall. i'm going to not reinstall the clock at all this time. if this doesn't work, i'll be forced to conclude i have broken hardware.
i'll at least now have time to save up. i'll have to think carefully about whether or not i decide i want to mix on the m-audio card in the mean time.
well...the last, final check will need to be an install on a vanilla xp. but, it would make no sense to think that would work. it's just a final confirmation.
the fade ultimately sounds like some kind of limiter that kicks in around 5000 hz, and makes the end result sound very compressed. i can't mix around this.
i'm down to my last reinstall. i'm going to not reinstall the clock at all this time. if this doesn't work, i'll be forced to conclude i have broken hardware.
i'll at least now have time to save up. i'll have to think carefully about whether or not i decide i want to mix on the m-audio card in the mean time.
well...the last, final check will need to be an install on a vanilla xp. but, it would make no sense to think that would work. it's just a final confirmation.
the fade ultimately sounds like some kind of limiter that kicks in around 5000 hz, and makes the end result sound very compressed. i can't mix around this.
things are back to "normal", now. i'm just not sure that's for the best, quite yet.
returning back to the initial script actually created the following flow:
1) install windows - with streamci.dll & the clock in place
2) install the m-audio drivers & other basic drivers. reboot.
3) install tons of software & the mixer & line6 drivers. reboot.
4) on the reboot, streamci is run as a dll. then the script runs: which deletes streamci.dll and breaks the clock.
when it came back up, something familiar happened that i hadn't seen in a while: it took a very long time to load cubase. i can see now that this is a consequence of breaking the clock. but, only the streaming server needed to be reinstalled. the other two appear to be unused by any of the cards. i was certain about that one, and less certain about the other two.
my hypothesis is that what i want to happen is for the drivers to install properly, and then i want to break the clock and reinstall it in such a way that the drivers aren't directly connected to it. that would make sense if i was essentially getting a conflict between the clock in the mixer and the clock in software. i don't want these synced. i think that breaking it and reinstalling it essentially unsyncs them.
so, it's stable. i'm quite confident that this is the setup that i've had over the last year and a bit - that is, this is workable and i'm not worried about it breaking.
but in the course of playing with a hundred things, i think i managed to make it sound a little better. and, now i'm wondering if i can't find a way to get back there.
what i'm going to want to do is test it against other cards. what i want is not the "best" sounding output but the most accurate sounding output. the bass sounds great, and the highs are stable but they seem a little weaker than they were at points, previously. but, is it the case that i was exaggerating the highs (and just like that better) or is the case that i'm still a little flat?
obviously, i can't expect everything to sound identical. but, the laptop is still the flattest source, and the best comparison i have.
should i be convinced that the tracks are clean, i can get back to mixing. if i'm not convinced, i'll have to take a look at possible approaches to aligning the output on the card. and then lock that down into the script.
the laptop is not quite able to produce the same bottom end, but i am legitimately happy with these mixes. it'd be really nice if i could just move on already. soon, hopefully....
returning back to the initial script actually created the following flow:
1) install windows - with streamci.dll & the clock in place
2) install the m-audio drivers & other basic drivers. reboot.
3) install tons of software & the mixer & line6 drivers. reboot.
4) on the reboot, streamci is run as a dll. then the script runs: which deletes streamci.dll and breaks the clock.
when it came back up, something familiar happened that i hadn't seen in a while: it took a very long time to load cubase. i can see now that this is a consequence of breaking the clock. but, only the streaming server needed to be reinstalled. the other two appear to be unused by any of the cards. i was certain about that one, and less certain about the other two.
my hypothesis is that what i want to happen is for the drivers to install properly, and then i want to break the clock and reinstall it in such a way that the drivers aren't directly connected to it. that would make sense if i was essentially getting a conflict between the clock in the mixer and the clock in software. i don't want these synced. i think that breaking it and reinstalling it essentially unsyncs them.
so, it's stable. i'm quite confident that this is the setup that i've had over the last year and a bit - that is, this is workable and i'm not worried about it breaking.
but in the course of playing with a hundred things, i think i managed to make it sound a little better. and, now i'm wondering if i can't find a way to get back there.
what i'm going to want to do is test it against other cards. what i want is not the "best" sounding output but the most accurate sounding output. the bass sounds great, and the highs are stable but they seem a little weaker than they were at points, previously. but, is it the case that i was exaggerating the highs (and just like that better) or is the case that i'm still a little flat?
obviously, i can't expect everything to sound identical. but, the laptop is still the flattest source, and the best comparison i have.
should i be convinced that the tracks are clean, i can get back to mixing. if i'm not convinced, i'll have to take a look at possible approaches to aligning the output on the card. and then lock that down into the script.
the laptop is not quite able to produce the same bottom end, but i am legitimately happy with these mixes. it'd be really nice if i could just move on already. soon, hopefully....
Friday, August 21, 2015
my original script notes indicate that i had the file deleted along with a pile of networking files. i no doubt thought it was for network streaming. deleting anything that could be used for behind the scenes network traffic was the primary motivation in cutting the install up. it was just purely by accident that i was deleting it, and the only reason i put it back was that the dialog box was annoying.
so, this is a little embarrassing, really - i caused this problem myself. but i'm now absolutely certain it's resolved, too....
so, this is a little embarrassing, really - i caused this problem myself. but i'm now absolutely certain it's resolved, too....
my idea that i got a corrupted dll in an update is not right. the modify date seems to be connected to the burn date on the dvd; the dll is passing a crc with a version from 2001 - meaning the dll has probably *never* been updated.
this piece of gear has a bad reputation, and i guess this is a plausible explanation for it - the driver install breaks it. i just never noticed because i always deleted the class installer before the install finished.
this piece of gear has a bad reputation, and i guess this is a plausible explanation for it - the driver install breaks it. i just never noticed because i always deleted the class installer before the install finished.
yeah. that was it. i'm getting very, very clear and stable highs - so clear, it's kind of shocking that i ever thought what i was getting before was clear. but, the bass seems a little weak. i'm not sure if that's relative, or if there's some remnants floating around in the registry, so i'm going to put the script back to the way it was - delete streamci.dll and break the clock on install - test a little further and then probably do another reinstall.
Thursday, August 20, 2015
the streamci.dll file on my xp disc is dated to april, 2014. so, it must have been updated in one of the very last xp updates that i slipstreamed in. it might have broken something. if i can demonstrate that this is stable, i'm going to try another reinstall with an older version of streamci.dll - one that is at least as old as the drivers.
simply disabling the wdm driver produced a stable output, but it was a little flat - it didn't sound right.
the autorun in the registry is running streamci.dll as an executable and carrying out a number of commands related to the wdm and the clock. that makes perfect sense - it's the class installer. but, that seems to be what's screwing it up. and, it's still the clock. and still windows, like i thought at the very start...
streamci.dll was also in my initial delete script, but i took it out a while back because i'd get "missing or corrupt" errors on the first boot after a driver reinstall. i can't date this, but it's not that long ago. april, maybe, even. i can see now why that is. but, in the past, that means the autorun didn't actually execute - because the dll wasn't there.
so, i tried reinstalling the drivers with the streamci.dll deleted and the autoruns removed (i'd just get the error if they were there...) and it seems to be stable.
the autorun in the registry is running streamci.dll as an executable and carrying out a number of commands related to the wdm and the clock. that makes perfect sense - it's the class installer. but, that seems to be what's screwing it up. and, it's still the clock. and still windows, like i thought at the very start...
streamci.dll was also in my initial delete script, but i took it out a while back because i'd get "missing or corrupt" errors on the first boot after a driver reinstall. i can't date this, but it's not that long ago. april, maybe, even. i can see now why that is. but, in the past, that means the autorun didn't actually execute - because the dll wasn't there.
so, i tried reinstalling the drivers with the streamci.dll deleted and the autoruns removed (i'd just get the error if they were there...) and it seems to be stable.
no, it seems like it's a driver conflict after all. the driver that's in conflict?
itself.
might explain why it didn't want to isolate...
the mixer loads two drivers: one for direct access, one over "wdm". i'm almost certain that the final solution, for now, is to disable the wdm driver.
the wdm driver is being used to playback final mixes over foobar, and i would absolutely like to resolve the concern. it wasn't like this before. but it seems to be a registry add.
if i uninstall and reinstall the drivers, it will be stable after the first reboot and gets funny on the second. some values are added to the registry on start-up. this seems to be the actual cause.
for now, i'm not worried about fixing the wdm streaming. i'll just leave it off when i get back to it. when i wake up...
but, again: it's bizarre, difficult to isolate for problems, one after another.
itself.
might explain why it didn't want to isolate...
the mixer loads two drivers: one for direct access, one over "wdm". i'm almost certain that the final solution, for now, is to disable the wdm driver.
the wdm driver is being used to playback final mixes over foobar, and i would absolutely like to resolve the concern. it wasn't like this before. but it seems to be a registry add.
if i uninstall and reinstall the drivers, it will be stable after the first reboot and gets funny on the second. some values are added to the registry on start-up. this seems to be the actual cause.
for now, i'm not worried about fixing the wdm streaming. i'll just leave it off when i get back to it. when i wake up...
but, again: it's bizarre, difficult to isolate for problems, one after another.
Wednesday, August 19, 2015
dammit.
again.
ugh.
i'm going to break the clock again and see what happens...
it seems like that flattened it out. which is weird. because i thought it was the problem in the first place. and it left it a little jagged - but at least it's not bleeding.
i have an idea...
there's three drivers attached to the system clock in xp. there's the streaming proxy, which i'm nearly absolutely certain was functioning before this mess. there's the microsoft streaming proxy clock, which i'm pretty sure was functioning. and, then there's the microsoft streaming proxy quality manager which i have little to any memory of. i suspect it's the third of these...
when i modified the script, i removed the deletion on all three. so, the issue may have been sitting under my nose the whole time.
i'll have to test. again. ugh. but, it's gotta be it.
again.
ugh.
i'm going to break the clock again and see what happens...
it seems like that flattened it out. which is weird. because i thought it was the problem in the first place. and it left it a little jagged - but at least it's not bleeding.
i have an idea...
there's three drivers attached to the system clock in xp. there's the streaming proxy, which i'm nearly absolutely certain was functioning before this mess. there's the microsoft streaming proxy clock, which i'm pretty sure was functioning. and, then there's the microsoft streaming proxy quality manager which i have little to any memory of. i suspect it's the third of these...
when i modified the script, i removed the deletion on all three. so, the issue may have been sitting under my nose the whole time.
i'll have to test. again. ugh. but, it's gotta be it.
i swear, my body has loosened up by a factor of 80%, if such things can be measured, which of course they can't. but whatever stress buildup existed is fading away. and, that should actually help me focus a bit better.
it should also help me kick the cigarettes. it seemed pointless when i didn't know how much longer i'd be alive...
i bought one more pack for the next day or two. i need to put the election shit down and get through the remaining tracks for this. that last track is bugging me, because it just sounds kind of odd. i may end up replacing it after all. and, the next few should be pretty quick to pass over.
it should also help me kick the cigarettes. it seemed pointless when i didn't know how much longer i'd be alive...
i bought one more pack for the next day or two. i need to put the election shit down and get through the remaining tracks for this. that last track is bugging me, because it just sounds kind of odd. i may end up replacing it after all. and, the next few should be pretty quick to pass over.
checks
hi.
just letting you know that my disability extension was approved, so i have checks ready to give paul for the rest of the year, whenever he's home to take them.
j
just letting you know that my disability extension was approved, so i have checks ready to give paul for the rest of the year, whenever he's home to take them.
j
Tuesday, August 18, 2015
not updating i still don’t fully understand this
this one is a little different. i initially rendered it on july 5, with an unknown combination of ram and save mixer settings - but that i think was close to mostly saved settings. the fact that it sounded bad was one of the first things that tipped me off to the broken drivers. i noticed that it sounded better in cubase than it did through foobar, so i re-rendered and re-uploaded it on july 12th with completely saved settings.
it doesn't pass an a/b with reset mixer settings. so, i'm just going to leave it as it is.
https://jasonparent.bandcamp.com/track/i-still-dont-fully-understand-this
it doesn't pass an a/b with reset mixer settings. so, i'm just going to leave it as it is.
https://jasonparent.bandcamp.com/track/i-still-dont-fully-understand-this
Subscribe to:
Posts (Atom)