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.

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.

and, the highs are a little weak in the same spots. ok. it seems like i'm flat. let me convince myself entirely. but i think i'm back in business. i may have to revisit a few things for a slight treble boost, but i think i'm ready to go.

from the rooftops, shout it out...

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....

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....

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.

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.

yeah, my back-up script change-log is dated to april 26th and it doesn't make mention of streamci.dll. so, it was taken out of the script in may or june. i may have previously never attempted to install drivers without deleting streamci.dll first.

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.

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.

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.

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.

my odsp was extended until 2020.

i can stop worrying about that, now.

by 2020, i am exceedingly confident that i will complete my discography and be moving into phase 2.

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

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

not updating in some neighbourhoods the boogeyman is slightly more than an imaginary monster

same as the others.

https://jasonparent.bandcamp.com/track/in-some-neighbourhoods-the-boogeyman-is-slightly-more-than-an-imaginary-monster

https://jasonparent.bandcamp.com/track/ogyanemob

not replacing thug culture is enforced by the media from the top down

yeah, this is static.

the gain on the tracks is clipping mildly, but it's covered by the compression on the master. it took me a few tries to figure it out (and fears my drivers were broken again...), but rendering the tracks separately through the initial eqs is introducing clipping that transfers over - because they clip clean, when not sent through the compression. that's not something i can work around. modifying the volume will modify the null.

again: the neurotic geek in me wants bitwise perfection, but the a/b's tell me this is pointless, anyways.

https://jasonparent.bandcamp.com/track/thug-culture-is-enforced-by-the-media-from-the-top-down

contemplating replacing thug culture is enforced by the media from the top down

i'm still determining whether i want to replace this one or not for idealist mathematical reasons of it being bitwise identical to the initial save - although that's going to be false for the bulk of what i end up constructing. but, the reality is that it also fails the a/b and anything i replace the existing file with will be inaudibly different from the existing file. so, this is also done, for all intents and purposes.

https://jasonparent.bandcamp.com/track/thug-culture-is-enforced-by-the-media-from-the-top-down

not updating use value is somewhat difficult to define in the human propensity towards artistic expression

this track has also not been modified, and also failed the a/b.

https://jasonparent.bandcamp.com/track/use-value-is-somewhat-difficult-to-define-in-the-human-propensity-towards-artistic-expressio