Maybe a senior elf will drop by and explain it.
Alternately we may be looking at the problem. It’s supposed to make a difference and yours doesn’t work.
And now for the darker side. If we haven’t hit something by now, there may be no solution.
Koz
There is this from the wiki.
https://manual.audacityteam.org/man/faq_recording_troubleshooting.html#skips
“On some Macs, the buffer may need to be reduced to zero.”
Koz
Thanks again Koz, I really appreciate your diligence, knowledge and kindness trying to solve this.
Buffer length having no effect is indeed strange.
I am going to try a power conditioner I have in another rack and see if that helps. If I can go a day without a glitch, I’ll consider that an improvement.
Could you shed a little more light on the type of memory thing though? If I could find better / more appropriate memory, I would look for that.
If you have a link, I’d really appreciate it.
We’re looking for broken memory. You shuffled across the rug and didn’t discharge yourself while you were installing the strips, or even got broken memory out of the static package. Not likely, but it does happen. You wear a wrist strap while you’re in surgery, right?
The checker applies different patterns of data to the strips and looks at what comes back. Simple as that. If they don’t match, it rings bells. There is one trick to this in that the operating system should take up as little memory as possible so to check as much as possible. The floppy trick ran the whole thing in DOS, so the OS and the whole environment fit in 1.44MB. The machine I’m typing on right now has a kernel_task taking up 700MB, so that’s the amount that the checker doesn’t have access to.
Chances are if your checker didn’t turn up anything by now, it’s fine.
Koz
an old Mojave machine
While you were in there, did you turn up a watch battery?
I wonder how they do time and date now? Is that why the main battery no longer comes out?
Koz
I didn’t have to dig too deep to replace the hard drive and memory, so I might have missed a watch battery if there was one there. The main battery is still removable in this model.
This is quite a long thread so I may have missed it, but have you posted an audio clip demonstrating the problem?
If not, please post a short WAV file (just a few seconds) to illustrate the problem.
(This may not tell us anything new, but the normal approach to this problem is not workings, so perhaps we are overlooking something)
Just a small follow-up here.
I have everything connected to a power conditioner, and I still get completely silent drop-outs here and there that do not triggere Audacity’s ‘dropout detection’.
I also still can’t see any effect in changing the buffer size.
As of now I’m going to chalk this up to some hardware defect somewhere - either computer or interface (an expensive mixer).
Disappointed, but undeterred, I continue to rip and manually correct these glitches.
computer or interface (an expensive mixer).
Just reading that over again. We know nothing about the mixer and the connection to the computer. I don’t expect the USB connection to be failing, that usually gives Audacity a “stuck” cursor as the bitstream stutters or misses a beat, but yours is the exact symptom you could get if somebody “killed the key” on the mixer for a split second. It’s upstream from the A/D converter, so the stream would just keep right on trucking, but the show would be silent, and it would be missing for the right amount of time.
How to test.
Ummmmm.
This doesn’t have to be Nashville Quality, but do you have an independent way to record the speaker, Control Room, or house feed from the mixer while you’re making a dub? Wouldn’t it be special if the house feed had a hole in it at the exact point the Audacity feed dropped dead?
Koz
It’s a Rane 70 direct via usb into a macbook pro (older model, brand new SSD and brand new memory).
Just want to confirm this is exactly the effect - the audio continues playing but there is a perfect digital silent portion. When I say perfect, I mean it cuts off very briefly (sub-ms level), and it’s instantaneous, no fade out (like a fader) or clicks (like a loose cable).
I’m not performing, I have it set up in my studio strictly for archiving vinyl right now. I could indeed record the room but it would just show the same audio glitch. I hear these while I am ripping (then I mark it, rewind the record, and repair the audio manually in post).
I’m not recording the master output, I’m using the mixer as a USB audio interface and reading the direct feed off the turntable pre-amp.
The only connections are turntable phono → mixer phono in, and mixer usb → macbook.
I’ve tested it, and none of the mixer controls affect the recording, the feed I am getting off this particular channel is pre-everything.
I have considered attempting to tap the master though, but unless there’s a way to select which channels to record in audacity that I don’t know about, that would involve creating an aggregate device, and then I do actually have the potential for the problem you suggest - the mixer processing is then another stage the audio passes through, more colour, more potential for errors.
Is that what you are suggesting though? That maybe a mixer fader was getting bumped (or some other physical act) causing the glitches?
I’m going to make it a point to share some audio of the glitches. I literally rip these records for 8 hours a day so there is no shortage of examples.
Here are some demos of the glitches:
http://s000.tinyupload.com/index.php?file_id=74596849719449753500 - 4mb zip of 5 wavs
These happen about once every 15 minutes of recording - ie if I record for 30 minutes, I’ll get another one. Unfortunately, it’s not that predictable though when they will occur. Definitely a big random element - sometimes I don’t get them at all.
I have been following this thread with some interest - thanks for posting those samples. So while koz and steve are mulling over your recordings, I took a quick look at some of them, myself. On the three tracks I happened to look at, each one had a gap of exactly the same size (3763 samples to my eyes). I think you had previously measured this gap,
it doesn’t seem to hold any relevance to me, either.
From empirical evidence, it seemed as though the recording was delayed (i.e. the drum beat after the gap was late!) This is also confirmed by this clip from glitch05, where the levels on each side of the gap seem to be identical.
This seems to be at odds with your previous observation:
so these may be different problems or I may be interpreting things incorrectly.
Because the glitches seem to be exactly the same size, my gut tells me we are dealing with a software or firmware problem. It could be audacity.
I noticed your mixer had two USB outputs?! I assume you have tried both of them. Have you tried another USB mixer? Did you ever try another computer?
At this time I am going to join koz and steve with their mullings… 
…still mulling…
Just double checked and I think you’re right…at least in some cases, so I’ll def check more. Thanks for the sanity check!
What I did was I marked the glitch, then I took a recording of the same section, and overlayed it as close to sample-accurate as I could. Sure enough, during the first ‘matched’ portion, you can hear the two tracks overlay and basically amplifying each other. Once the glitch happens, there is a delay introduced.
What is most interesting to me about that is that means, if each of these glitches is indeed injecting a silent delay, then that means the longer I rip, the more delay is introduced.
I’ll make my next experiment to see if there is anything consistent BETWEEN glitches - maybe there’s a relevance to how long it takes each glitch to occur.
Thanks again for the sanity check.
Here’s an audio recording - sorry to switch hosts mid-thread but the other one now isn’t working - go figure.
https://sendeyo.com/en/b30a19a750
I checked the 5 glitches I sent in the attachment - so 1,2,4, and 5 seem to behave like you suggest - adding a glitch of 3,762 silent samples.
However glitch 03 does not follow that scheme - if I delete that missing portion, it sounds out of time. Also interesting to note, glitch03 is 7,462 samples long vs the rest being 3,762. That’s CLOSE to double the original glitch…related? Maybe the glitch is actually double and I’m just not measuring from the right spots…there isn’t a very clear break like in some of the others… but that would make sense if it’s delaying the first glitch-period, and silencing the second.
So it could be even less consistent - sometimes adding a delay, sometimes dropping out, or in this case both.
Just tried the other USB output on the Rane - exact same behaviour. Next step is a different computer.
For posterity, first glitch appears (in this particular instance) at 4 minutes, 12 seconds, and 10820 samples.
I’m not sure if anybody is still following this, but I have an update.
So I hit this machine and this setup pretty hard, usually pretty constant for the entire workday - I had just learned to accept it, I would listen closely, when I heard the glitch, I would mark it. Then I would go back and edit out those 3,762 dead samples. Not ideal, but I got pretty quick at it.
I recently took about a month off - no updates to Audacity, the OS, or the hardware… and I have yet to encounter this problem since.
No idea - the only thing I can think of that changed is I’ve definitely unplugged / replugged the USB cable a few times.
Just another mystery of the universe…
Thanks for posting this update… 