Print

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

[MusicHawk]

My music playback PC has developed an annoying behavior, and it seems to have appeared after upgrading from MC from to 13.0.172 from .171.

I play a large library (60K+ tracks) randomly. MC is set to "Cross-fade (aggressive)", 2 seconds, and "do not play silence). These settings provide a radio-station-style segue between tracks, so, anything less than a smooth transition is noticeable. I have NEVER heard a problem with this until now.

After the upgrade, I'm hearing an audio dropout of 1/2 second or so. It's like someone briefly switched audio off then back on -- a burp. It happens maybe 20% of the time.

The burp happens about 2-3 seconds before the end of the playing track. It's repeatable in that I can replay the same sequence, track1 moving into track2, and the dropout of track1 happens, same place, again and again.

One guess, given that MC is set to overlap the two tracks, is there's something about the two tracks plus MC's handling of them that briefly suspends the playback audio stream. Perhaps the playing track requires a bit more processing than usual before it can be played (most are highest-quality VBR LAME MP3s). Maybe if reading and readying the new track sometimes takes a fraction of a second longer than "normal" MC's playback of the current track hangs until the new track can be started and mixed in... just a guess.

A clue: When the dropout happens, MC's track info area at the top, which normally shows song title, artist, etc, briefly says "buffering". So I tried increasing MC's "prebuffering" (whatever that means) from default 6 seconds to 10 seconds, but it didn't seem to help; I still hear plenty of dropouts.

I believe the dropout happens when MC starts up the next track per the 2 seconds overlap (it doesn't really cross-fade, fortunately). However, I've listened to zillions of tracks in the past year with exactly this setting and never heard the dropout until upgrading to 13.0.172. So, has something changed in it that could cause this annoying problem?

There have been no other changes in MC's configuration.

I'm using two DSP plug-ins, the built-in Volume Leveling (replay gain processor) mode, and the external plug-in AudioProc, a wonderful radio-station-style compressor. But these have been part of my MC chain for quite some time, and they are processing MC's output while the dropout seems to be at MC's input. Disabling them didn't cure the dropouts.

The computer is as it has always been, good speed, good RAM, good drive, etc. There is NO firewall or anti-virus or anything else running that would limit MC's ability to quickly access the music files. The only computer changes are the periodic Microsoft Windows XP updates (including several a few days ago) typically described as security fixes.

I can only point to .172 as the culprit, unless there's something else to check.

[JimH]

Build 172 has been out for a while, with few problems reported, so it would be surprising if that's the cause.

The links to "Weird Problems" and to "Stability" in my signature might help.

[MusicHawk]

Yep, I can't "prove" it's .172, just report as many details as I can in case Matt or someone recognizes this is a side-effect of another change.

Re no other reports, I wonder if the dropout behavior only happens -- or is only noticeable -- when using cross-fade (aggressive) with a notable overlap (mine is 2 seconds). Anyone else doing this? If someone is not using this overlapping tracks mode, perhaps MC doesn't encounter the situation that causes the problem, OR it happens but isn't noticeable.

[MusicHawk]

Correction: My playback PC was previously running 13.0.167 and did not have the dropout. It was upgraded to .172 yesterday and acquired the dropout.

(I confused myself because my ripping/editing PC was running .171 and also was upgraded to .172 yesterday, but the playback PC isn't upgraded as often... if it ain't broke....)

To try to isolate the problem, I'm reverting my playback PC to .167 to see what happens. I'll report back.

[globetrotters1]

I have that too with version 172 (but I was too shy to mention it as it is rare )

And in very rare cases the program hangs with the message "buffering" (happened let's say in two days once or so)

And another thing I have also in very rare cases: the program switches sometimes from "cross-fade (smooth) - 2 sec" to "gapless" without any user intervention... next track might be fine again... also not reproduceable

[JimH]

If the file is unavailable, for whatever reason, you may experience this.  There are lots of possible causes -- drive errors, drive spun down, controller errors, network problems, Windows process blocking, etc.  It is possible that MC has an unknown problem, though this is not the most likely cause.

[MusicHawk]

Update: I tried 13.0.167 and discovered the the audio dropout problem -- accompanied by MC showing a flickering "buffering..." -- happens in .167 too, just not as often. Maybe it happens once an hour in .167, and every 5 songs in .172. I disabled DSP plug-in AudioProc and the drop-out still happens.

The implication is that whatever the cause, MC has become less tolerant of it from .167 to .172. Or maybe my PC has developed a problem, though I have no indication of this. I understand that external factors can mess up MC. so I'm working on the PC right now, cleaning up the drive, making sure nothing is running in memory that isn't required (there already is no firewall, AV or similar), etc. The PC is quite beefy -- 2.8mhz dual core, 2gb RAM, 750gb SATA drive.

But even if the PC is somehow sluggish, why would MC be so sensitive to slightly slow PC and/or drive response? I also play MC on an old laptop with an external USB drive and do not normally have this problem.

So I wonder what's up? What does the "prebuffering" setting do -- I moved it from 6 to 10 with no improvement?

The biggest clue is that the dropout/buffering behavior is repeatable. Once it happens at the transition of two songs, I can reply the final part of the first song over and over, and every time, the same anomaly happens during the 2 second overlap segue as the new song loads/starts This is why I think there's something in MC that is somehow involved.

I'll report back after switching back to .172 and doing lots of PC "just in case" cleanup, defrag, etc.

[Vocalpoint]

Or is only noticeable -- when using cross-fade (aggressive) with a notable overlap (mine is 2 seconds). Anyone else doing this? If someone is not using this overlapping tracks mode, perhaps MC doesn't encounter the situation that causes the problem, OR it happens but isn't noticeable.

MH,

I have the identical settings as you...the Aggressive CF with a 2 second overlap and I have had no issues. Running .172 as well. For DSP - I have the EQ and the Volume Leveling inline at all times.

[JimH]

Musichawk,
Did you look through this thread for ideas?

Weird problems

[MusicHawk]

Yes, I checked the weird problems list and looked at items that might apply. I completely cleaned up and defragged both drives. They are performing very well, both SATAs, less than 1/2 full -- Windows and MC on one drive, the music files on the other drive. Nothing else running.

I still think there is something going on in MC, because of two facts:

1. The problem happens ONLY at the segue transition between tracks, at the exact point where the next track should start playing -- in my case 2 seconds before the playing track ends. MC flashes "buffering..." and the audio drops out/suspends for 1/2 a second. If there was a computer or drive or driver performance problem, how could it show up ONLY at this exact point?

2. The problem is repeatable. When the playing track drops out at a seque, I can replay it and it drops out at the same point, again and again. Yet if the track is played without segueing to the next track, there's no drop out. So the problem isn't with the track as such, the problem is with the transition between tracks -- SOME tracks.

And maybe a clue... the buffering.../drop out behavior happens in .167, but more frequently in .172. So, what changed in the playback transition code between these versions?

I haven't spotted any other pattern, such as differences in track format (all are MP3) or sampling (some are VBR, some fixed rate, but this doesn't seem to matter) or anything. And now that the media drive has been defragmented (which took hours), the MP3 files are presumably contiguous and likely aren't where they were before. This means the drop out problem is based on MC's USE of the files, not the physical files themselves, right?


I'm hoping JR/Matt can stare at the code that handles track overlapping transition/segue to see if playback could hang briefly while waiting for something: Maybe getting the next track's cover art (files also defragged)? Or maybe writing the Last Played info to the ending track while also trying to load/read/start the new track -- the library has more than 63 thousand tracks and the primary smartlist currently has more than 19 thousand tracks -- maybe introducing real-time performance issues? Or could something about the computation of the overlap (2 seconds in my case) be a factor?


And I'm still wondering about the prebuffering setting? If it doesn't refer to a time lag between when MC fetches data from disk and uses the data for playback, then what does it do? And if it DOES do what I'm guessing, then it would seem to isolate MC from reasonable fluctuations in drive performance. Otherwise, what is being "pre" buffered?


I understand that the same chunk of code is used in MC14 so investigating this wouldn't be a wasted effort. (I already own MC14, just waiting for a bit more stability.)

[MusicHawk]

MORE CLUES..

The audio dropout 2 seconds before the end of the current song is still happening -- randomly, not a lot, but a few times per hour. VERY ANNOYING.

I realize there aren't many complaints, but this problem is perhaps not encountered by users who don't set MC to playback mode "cross-fade (aggressive)" with 1 sec or more of overlap. I suspect this is the only mode where track 1 is still playing as track 2 starts, therefore audio dropout of track 1 is audible -- VERY. I LOVE this "radio station seque" mode, so if there's a problem I hope it will be corrected.


I've narrowed down the dropout/buffering problem to the track that is just being started. I can repeat the problem endlessly by going from song A to song B. But if I go song A to song C, no problem.

I've done everything I can think of (and suggested in Jim's weird stuff list) and haven't cured the problem. It's a beefy system, nothing else running except Windows scheduler (which kicks off a backup program overnight), no extra cards/drivers/firewall/AV, defragged drive, etc.

COULD IT BE... that the buffering/dropout is NOT due to loading the next music track, but loading the next track's COVER ART? I use only external files, no images stored in the music tracks. All my cover art images are on ONE folder: more than 12 thousand images. So I could speculate that Windows sometimes has a delay when locating a file. I tried turning off cover art and other display elements by using the mini view, didn't help. But maybe MC locates and loads the cover image whether it is visible or not?

HOWEVER, if the problem is due to loading the image, why do just certain music tracks, again and again, have this problem? Is there no buffering/caching of cover images at all? AND, sometimes the problem happens with a music track that does NOT have an image file associated with it.


AGAIN: It sure would be helpful to get some info on what MC is doing internally at the transition point that could trigger frozen playback and intense "buffering..." messages for 1/2 a second at the exact point when the new track is to start playing.

For instance, why doesn't the pre-buffering (set to 10 seconds) isolate MC from file/drive hiccups? What does this setting control? What is it buffering at this point, and what is it not buffering?

[JimH]

It is likely to turn out to be something like this problem (from the Weird Problems thread)

Playback hesitates / pauses every 2 or 3 seconds
Another program, catwalk, was the cause.
http://yabb.jriver.com/interact/index.php?topic=53167.0

If you think it's specific to your settings, please change them.  See if you can find one that works and one that doesn't.

[marko]

FWIW, I get these too, and have had for a very long time.
I've never persued it as no-one else has ever mentioned it, and more importantly, I am unable to make it happen at will, and I think it's unlikely to be an MC problem.

My experience is not limited to the start/end of a track, the audio just cuts out for a second or two, like back in the 'old days' when listening to AM radio in the car and driving under a bridge.
I've never tried trouble-shooting as I've no idea where to begin.
It happens very infrequently indeed; I could not gaurantee a drop-out during every MC session, for example.

PCs are more fickle than the fairer sex at times

[MusicHawk]

After much more observation and experimention:

My audio dropout is not actually random, and it is not mid-song. It is exactly at the transition from the playing track to the new track. exactly when the new tracks starts.

It is only audible if the tracks are set to overlap (cross fade aggressive mode). Changing the amount of overlap in MC moves the drop-out point.

I believe the problem is entirely due to interaction between MC -- when overlapping tracks -- and certain specific tracks that MC somehow can't promptly load and play -- instead stopping audio while "buffering" for a second.

The only hard-to-pin-down variable is that the drop-out only happens with some pairs of songs. It is repeatable with those songs/tracks. I can't see any difference between them and others -- some are 2-channel, some 1-channel, all kinds of bit rates, some with cover image, some without.

For instance, I just found a song pair where audio drops out when transitioning. I can replay the transition and it always happens. I also found some other second tracks where the same thing happens when they follow the first track, but not when they follow other tracks. So the problem isn't tied to the second track. But this doesn't prove the problem is the first track either, because with most of the second tracks I tried, the problem does NOT happen. There's something about the interaction of certain tracks during an overlapping transition....

To solve this, the precise behavior information has to be considered by someone (Matt?) who knows exactly what MC is doing at the track-transition point in "cross fade aggressive" mode. The possibility of playback stopping briefly should be evident in the code -- the same code segment that displays a flashing "buffering" message during the silence.

For instance, knowing what the code is doing would explain why this happens only when starting certain tracks -- but is consistent problem with those tracks. I can imagine that maybe some tracks have faulty timing/gapless information. But blaming faulty rips is contradicted because the problem happens with old tracks and also with very new rips, therefore tracks that had different rippers/encoders/settings. What could they have in common?

[JimH]

Have you seen this thread on the MC14 board?  

[MusicHawk]

I just updated my last post with more info/testing.

>> Have you seen this thread on the MC14 board? 

The link doesn't work. What is the thread title?

[JimH]

Please try again.

[Alex B]

MusicHawk,

Your problem is probably caused by format differences.

MC cannot apply cross-fade if the sample rates and/or channels are not identical in both files.

As a workaround you can set DSP to your most common format. (44.1 KHz & 2 channels stereo, if most of your files are from audio CDs.)

48 kHz is also a good setting if your sound card does not natively support 44.1 kHz (in that case Windows will resample all 44.1 kHz output to 48 kHz anyway. MC has a higher quality resampler than Windows and it is better to not resample twice).

[MusicHawk]

Alex B:

Thank you for the advice.

Actually, it seems that MC CAN cross-fade (play simultaneously) different audio formats -- it does this reliably. The problem is the brief audio dropout / buffering message right at the point where the new track starts. Other than that brief event, both tracks are playing simultaneously for the specified overlap duration.

I was avoiding having DSP modify playback format thinking that action might be part of the problem, extra work at a critical point. On my PC all kinds of format tracks play just fine, so I did not suspect I needed to force anything. But you might know more about what's happening during simultaneous playback, so following your advice I just modified MC's DSP to force 16-bit, 2-channel, 44.1khz. I'll do some testing and report back.

There might be two problems -- a burp when transitioning between audio formats, and the 1-channel bug that Matt has just fixed in MC14 that I presume also needs to be applied to MC13. Two different problems could explain why I haven't detected a consistent pattern.