XXHighEnd

Hi Peter,

I have a recurring situation where some albums will stop playing part way through the playlist.  This happens on both hi-res and redbook.  XXHE may get through say three songs and then fail to start the fourth.  The fix is easy, I just go to click Alt-P on the shortcuts menu and the next song usually starts up.  After that sometimes the rest of the album will play out and sometimes XXHE will get stuck on another song or songs.  All tracks are played (eventually) and none are missed during the stop starting.

It ALWAYS happens on the same albums and for the same tracks in those albums.  For example, if I start playback from Track 1 and it pauses after playing Track 4, I can duplicate it by restarting playback from Track 4 (or Track 3 or Track 2 for that matter) and I will still get the "pause" even though the previous tracks have not been played this time.

Changing SFS to a high value (greater than 2) does seem to change the behaviour of the albums, but considering most will play happily at 0.10 or even 0.05 I am hoping for another solution.

Any thoughts?

Regards,

Anthony

Hi Anthony,

Since when is this happening ? (time / situation)

Peter

I think it has always been happening with 2.05 in some way.  Before I sorted out the correct setting for "Balanced Load" and/or "Nervous Rate" (I cannot remember exactly which setting I had wrong, but when it was changed to the current values in my sig it was like I had a whole new XXHE) those same tracks that used to stutter at their start now just pause, or at least that is how it seems to me, I might be wrong.  It is the same albums misbehaving.

Well, maybe you can find back the topic yourself, but what I recall is that we were dealing with this in this forum, unless it was someone else. Anyway, your system will have limits, depicted by the whole.
Do you still have that other PC around ? if so, it could be a good idea to try that with the same settings. That's at least a reference for me myself ... (dunno what to do with that yet, but it's better than thinking that your system is not on par).

Also, when you'd set all like you see in my sig, the sound may not be what you want, but at least that works so it could be a nice test. Btw, I play with 0.06 lately but this could be because of further improvements since 2.05. Otherwise 0.11 will work (if all is right).

Let me know ! (or ask etc.)
Peter

I do have the other pc and it does the same things, but I will put it in play tomorrow to see because it has not been used in a while.  As far as I know the XXHE settings on both AudioPC's are exactly the same as in your signature.

Most albums play fine at 0.05 for me...but some of them don't.

Something else :

If you are confident that one track (!) in the playlist (!) can be repeated for this behaviour, you can send me that file and tell me where it should stop (minutes into the track).

I can always try to observe what happens with it ...

Peter

Yes, but that's the thing (to grasp for you);
We can explicitly NOT say that when an album or track works with 0.05, they thus all must work. So I too can play with 0.05, but not forever, so to speak. I don't even start thnking about this, and switch back to 0.06. Not because I'm a fool or not eager, but because to me it is totally logic that limits are not fixed but depend on a 100 variables in such a system, including the length of the previous (!) track and where the current track is to be loaded from (think far and close memory if you like). And would my 0.06 not allow for VolUp etc., then I won't complain to anyone that this does not work; I buy a faster processor or more logically : I will try 0.07.
etc. etc.

Peter

PS: I now don't think it is useful to send that file as it seems clear that you cross limits (??). And you were honest with that of course :

Again something else :

When you play completely from RAM (RAM OS Disk, no Playback Drive, Always Copy to XX Drive) then if *then* playback stalls, something in the whole system stalled for quite some time (think something like a second). This is very very hard to imagine and therefore something should be seriously wrong.

That playback would stop in the middle of a track could happen, 5 years or so ago. I only want to say : I never ever run into such a thing and this is not because I know what I am doing or something; it just won't occur. And if I have my SFS too low, things just start to stutter heavily - that's all.

Peter

Hi Anthony,

Just my 2ct. I had similar issues. It was solved by lowering the Q1. Also my connection between music server and audio pc had to be lowered to 100mbit. But I think Q1 did the trick for me. I can now lower sfs to 0.07 without issues.
Regards.

Arjan, that's a "hefty" one !
Really smart thinking ...

Thanks for sharing,
Peter

It never stops in the middle of a track, it always stops at the end of a track, or the start of the next one, which is probably the same thing.  So the track plays out...silence...Alt-P...next track plays.  This happens with both my PC and the other one.  Thinking about it this could be the reason for Play button sometimes being active after an album finishes (in another thread).

Yes, I have a gut feeling that this is a network problem of some sort.  I will try your suggestion tomorrow.  If that does not work I will use the other AudioPC I have here as music server and see if that changes anything.

Anthony, we have been trhough this before, in IIRC the same fashion. Then too you later told that it is in between tracks. This is NOT the same as in the middle. Please find that other topic (should be your own).

Theoretically there can't be network traffic *IF* you have set all as should. Test it ? Activate Keep LAN Services and deactivate Persist. Remember the Always Copy to XX Drive.
Now get playing to work (from the RAM OS Disked PC).
Works ? then boot into Normal OS en Deactivate Use Remote Desktop; boot back into MinOS and control the Audio PC by normal keyboard, mouse and monitor.

Now you plainly don't have any network connection during playback.

Peter

Hi,
The connection was not the issue in my case for the album playback. It gave me ticks during playback and sometimes losing the RDP connection. It seems that my connection is not 1Gbit all the time, with 100Mbit (setting of the card) it is stable. The ticks came from automatic reconnecting of music server to audio pc all the time during playback. (bad 5e cable I think)

Lowering the Q1 from 14 to 4 did the trick for me to get continuous playback of an album. And SQ is still fine!

regards

Other AudioPC is in the system now...has the same XXHE settings and is the same computer except for the cpu...it pauses on the same tracks as my AudioPC.

Yes, we have been through similar stuff before.  In that other thread the problem was not fixed but the problem did change slightly to what it is now.


Well, there is certainly network traffic otherwise RD would not be working.  RD drops out and is unable to be resurrected (forcing a hard shutdown of the AudioPC) up to half a dozen times a day.  When this happens music will not play and re-connection is impossible so the hard restart is necessary.

I am having a number of small problems at the moment and I will work through them one by one in the hope that one of the fixes will help the other situations.  For your information, the other problems include hi-res and Tidal streams playing with light intermittent static regardless of SFS, although the control panel shows no errors.

Anthony

Probably the language thing, but my first post was clear that this happens when one track ends and the next begins.

Ok, what about it being non-sensical to let die out those topics (issues) without them being solved, to next in cool fashion start a new topic as if nothing happened ?

Your last post ... we dealt with all of that too. Maybe it wasn't solved, but all I recall of those things is that it ended up being OK. Apparently it is not, but this is not much managable in this way. ;)


and from me :


So what are you doing ?
I'm afraid you just testified that you're not trying what I am asking. This is fine of course, but then don't expect anything to change. True ?

Regards,
Peter

PS:
If you don't revisit this topic (may not have been yours) then I will.

PPS:
Please open a new topic for this, with your knowledge in advance that there's no single way this can be Tidal related, unless Tidal gives you flawed rips. Btw, Tidal Hires ? but please continue in the new topic; I'll deal with it in serious fashion as always.

PPPS: Yes, language problem (or poor reading); my bad anyway !

The stuttering problem was solved in that thread...I almost can't induce stuttering any more even with extremely low SFS...and it was solved because I realised I had a wrong setting that made the computer tooooo slow.  Now I have the "pause" problem and that is why I started the new thread considering that most people will have the correct (read your) settings in XXHE.

What I do have here are two different AudioPCs that suffer the same problem in the same albums and one of those PC's is exactly the same as yours on which you have no problems with these settings.  Something is going on...same PC same XXHE but I have problems here and you don't have that problem there.



The way I read that you were not really asking me to do that but just proving that network is not required for the AudioPC to operate properly.  I will do it tonight and report back.




No, not Tidal hires, Tidal and my hi-res files.  I have not tried any of either on this other PC so will do that as I get a chance.  I will open another topic, but will do so after I get through this pause problem if the other persists.

Anthony

Anthony,

It is still fine if you send me such a track. But it shoud be the most "fast" repeatable for me. Thus preferably one track only, and if two are required (like two in a sequence because otherwise it doesn't go bad) then two. And with description of course.

Read : I am the most happy to check this for you and solve a problem when one's there. But if you in between the lines start "blaming" your network, then we already know it's a moot thing. So it just depends on what your own thoughts really are. One thing we know : it is not your processor (good !). Of course I wasn't really suggesting it, but very far I obviously did after all. Anyway, good that this is out of the equation.

Now send me this file(s) ... really no problem.

Peter

I just did this, made double sure of no network connection and still had the pausing issue.  Next I will send you some files Peter.

Question meanwhile, Anthony :

I recall something similar from a farther past, and SOMEHOW this only happened to collection albums. I was totally puzzled by it. I also don't recall to ever solve it, though I never see the problem any more.

Is this from a collection album ?

Peter

No, not from a collection album...I don't really listen to them at all except for maybe the odd soundtrack, but have not noticed anything in particular with those.

Anthony,

I can be 99% sure only, but it looks like you have a ripping problem, or "source" problem otherwise;

I only have this album as an example but say that 75% of tracks are not on "stereo sample" boundary. So for 16/44.1 (what this is) the music data bytes should be divisable by 4 and in 75% of tracks on your album it is not (2 bytes remain).
My version of the same album is in 100% of tracks divisable by 4. Now :

I have just spent 2 hours in finding this after seeing other things I could not really proove to be wrong, just as I can not really proove that this is wrong really. Fact is (or seems to be) :
- You report this as an often recurring problem;
- I have never seen it (the past x years);
- Nobody else reported this (but may not tell a thing).

Point is also that with an SFS of 60 this just plays, but things are really complicated as with the very small SFS at the end of a track the remaining length is cut by two because of an otherwise too short remaining part (think like a buffer needing to play 1 sample which will never work out because of way too much overhead) - which thing does not occur at the larger SFS and *if* it occurs it is super super rare (chances is just 60 / 0.06 = 10000 smaller) *AND* it can be a bug in the program. But if so, why with you and never with me.
This thus, while I see that "half" sample boundary of which I am unsure what it can do (but if you some times doubted whether channels suddenly were swapped, then now you know why; I am not suggesting this, but if things are not cut somewhere, then this *will* happen and don't ask me where this cutting is supposed to happen - all made so long ago by now).

So what remains for now :
What is your ripping means, or otherwise what is the source ?
Maybe we can do something with the answer, or maybe other people speak up with the same problem "because".
Anyway at this moment I have to give up. For you may count :
If you have another means of ripping (or source) present in your library, use that and see whether it occurs with that too.

Regards,
Peter

PS: I totally forgot to explicitly tell you that it goes exactly the same here (tried with SFS = 0.06 and 0.08 and at the end of track 08 it stops; 60 thus works). Additionally, my own version (not 100% the same because a few 10ths of a second difference per track) keeps on playing. This may tell nothing much, but I still have to tell it, of course.

This is kind of a relief actually Peter, if I do have a ripping problem, and I am not going crazy.  I have spent so much time being annoyed by this and trying to track down the problem, so thank you for your time.

All CD's including the one I sent you were ripped on my workstation using dbPoweramp while I worked. I did wear out one drive and replaced it with a Pioneer Bluray but I cannot remember exactly which disks were ripped with which drive, although I do know that at least some of the albums that pause were ripped on the latter drive.

As it turns out I am at the moment sorting out a new ripping solution with a Plextor drive and a quieter PC than my workstation, but still using dbPoweramp which I most sincerely hope is not part of the problem.  The Plextor drive should be here in the next week or two and once it turns up I will put it in the workstation and rerip some of the problem disks.

Peter, is there a way to tell which tracks have the issue?  Can that be automated in some way so I know in advance which CDs to redo?

Much appreciated,

Anthony

PS: what ripping software do you use?

Anthony,

First off at this moment I can not be 100% sure it is the cause. It resides too deep to sort out. Point looks to be though : when the one is dividable by 4 and the other is not, one of the two have to be "wrong" as such, but I can't tell how harmful it is. It sort of requires the otherway around proof first : are ALL of my rips OK then in this respect ?
So I am not claiming it is (causes !) the real issue, but, it can't be 100% OK either.

When you switch on logging, and play a second, the X3 log file will show a "Fameous first" entry. The large number there is the number of bytes of the music data which for 16 bits and 2 channels needs to be dividable by 4. It is cumbersome to check, because it takes 1-2 minutes to check one album.
I can make something for it, if I had time. And I feel I have not. ;) The time would be better spent if I can counter attack it during playback ...

In ~ how much percent of tracks does this happen ?

I use EAC (when I did, which by now is quite long ago).

Peter

Anthony,

Another member has been so kind to tell me via email that he encountered the same problem with DBPowerAmp.
Context from myself : Over time I have run into a relative numerous problems with DBPowerAmp and only with that (obviously many ripping programs exist, but DBPowerAmp often has problems).

In this case said member enountered the problem "always in DBPowerAmp" and "never in XLD" (which is Mac). He also tells that he solved the problem for Windows (and DBPowerAmp) to rip to one large file with cue sheet (what we in XXHighEnd call Cue Files as phenomenon).

The latter is logic to me, as the problem can not happen then; you'd say it can happen at the end, but this is not really so. The explanation is somewhat more difficult but it is about the base data on a CD and how actually TIME determines the track boundaries (and now programmers have to make many difficult decisions because no 1/100th second boundary resembles "sample" boundaries (one sample lasts 22 microseconds). And regarding the whole CD, it is just data and the data ends where it does and it supposed to be OK always (and it usually is).

Anecdotical is that those Cue Files are exactly a huge problem for me (XXHighEnd) because the lot now backfires to the playback means (program). So now there the lot is to be cut into tracks while the .cue file again denotes in time with a resolution of 1/100th of a second.


At least you now may understand how it is not easy at all to even determine what is right and what is wrong or what works out as wrong or is possibly harmless.

Hope this helps you.
Peter

Ok I have had this problem also mainly with some Hires HD track downloads but also the odd ripped CD. When the SFS is set at 4 all albums play through but at .10 the CD's stop after track 2 and the Hires after one track some at two.

I have thought that ripping may be an issue for a while, so today I downloaded EAC and re-ripped two problem CD's. I have been using dbpoweramp for the last 5 years. Well on listening to the first EAC ripped CD it played all tracks and going back to dbpoweramp sure enough it stopped at the end of track 2.

Certainly appears that dbpoweramp has issues on some CD rips. I will try the other CD tomorrow. I don't know what I can do about the Hires downloads but I think its the same problem. I've just bought \HDtracks\Harry Belafonte\Belafonte_ At Carnegie Hall and it only plays one track 24/96 at a time in contrast HDtracks Black Sabbath Vol 4 24/96 plays all tracks. I've split Hires albums into as many as 3 files but still stops after one or two tracks.

SFS at .10 sounds so good its disappointing to reset at 4 and in Ram OS the difference is easy to hear.

Robert

Very interesting Rob, thanks for posting.  sort of nice to know I am not alone in this.

I might have a quick look at EAC.

Cheers,

Anthony

Hi Robert,

If you have such a file of which you are sure it always stops, can you switch on logging, let it play for a few seconds and send me the X3 log file of that ? (press Stop, grab the X3 log file and you can attch the file here if you want).

After that I may ask you to send the whole file to me (by filemail.com and if the upload does not take too long for you).

Regards and thanks,
Peter

Well, home from holidays today so I burnt a couple of my problem CD's using EAC instead of dBpoweramp and they both played through perfectly, so it does appear to be a ripping problem as you suggested Peter.

EAC is slower but both my CD's played perfectly after ripping. I will use EAC from now on although I have ripped most of my CD's. When I started out in computer audio I did in fact use EAC but paid and changed to dbpoweramp after TCA Chris C recommended it.

Robert

Robert,

For EAC counts : If you're ripping faster than about 4x - 6x, you often won't have correct rips. So this is just a hint that it needs its time (so to speak).

Peter

Yes I thought this may be the case suppose I will re rip the db ones over time.

Have you any luck with the hi res file I sent you?

I'm slowly converting all Saracon files back to original flac or wave. They definitely are better unprocessed.

Robert

I have ripped more CD's and each plays perfectly and whole albums with EAC. I've compared and although its close I now feel EAC is slightly better in sound over dbpoweramp.

Interestingly some of the problem CD's were encoded with HDCD but EAC ripped, now work perfectly. Thanks acg for bringing this to our attention.

All my HDCD encoded cd's  were problematic with DBpoweramp.

Robert

No problems Robert.  I am glad that we have been able to find a solution albeit requiring a lot of re-ripping of cd's.  Peter did mention earlier in the thread that he may be able to get XXHE to handle the error, which would be great, but he is very busy with other things so I doubt it will happen overnight.

In the meantime I will re-rip more of my cd's.  EAC should sound exactly the same and dBpoweramp or any other bit-perfect ripping software..but who knows?

Cheers,

Anthony

It should sound the same but I think the problem is dbpoweramp works too fast as Peter mentions.

EAC is a much slower method but perhaps captures more(this is subjective in the digital world as we are relying on a mechanical device to read the original CD accurately and software to process it).

The difference was marginal, I had to listen to a sparse Jazz track(End of the Line) by Randy Crawford and Joe Sample from Feeling Good album. In particular the bass and her voice seemed more natural.

Perhaps I imagined it like the difference in cables!!!

Robert

Robert,

Maybe I missed it, but what are your problems with HDCD albums and DBPowerAmp ? Or do you mean that it is always them failing regarding the subject here ? If yes, that would even be veeeery logic, because when a sort of natively those are 24 bits (or are converted to that, which I think is what happens) then it is not the easy "always two bytes" any more. It is now three (3 x 8 = 24) and if this is not recognized while the program chops off at /2 bytes (a bit hard to explain) then 50% chance this gives the problem of leaving one byte (and 2/3 of a sample) at the end.

I think it is fair to say that DBPowerAmp sounds worse for the resulting rips, because it has been repeatedly reported. Notice that I gain such data from posts like yours, Robert. Throughout time quite many of those popped up.

Thanks,
Peter

Actually my problem is with certain HD downloads not playing albums right through these are 24/96 and 24/192 or even more than one song would be good. None are ripped but downloaded in wave from respected web sites.

Robert

I have that problem too.

For the 24/ 96 and 24/192 HD downloads, as mentioned earlier in this thread, the problem goes away by increasing the SFS. I usually change it to 1 and those tracks play one after another without stopping. Also, as mentioned earlier, one loses the benefits of the lower SFS.

"boleary" Yes I'm aware of the SFS some Hi res play at 1 and the worst at 4. But quite a few play at .10. I think its solvable but not easy as some don't have this problem at all.
The more recent HD downloads of music recorded recently like Mark Knopfler's Tracker are perfect at .10 but Harry Belafonte's Live at Carnegie Hall will only play all at 4.

Robert

Thanks Robert, I was just clarifying the the HD HiRes issue has nothing to do with DBPowerAmp.

I have ripped HiRes with DVD audio extractor and these play back no problem at .10.

There definitely is a problem with dbpoweramp and some ripped CD's and in association with using XXhighend playback and my computer setup. After extended listening last night I feel the EAC re ripped albums are better sounding.

I must qualify this by saying that a lot of my early rips were done on a laptop so this could also be a factor.

Certainly using an Asus BC-12D2HT x12 blu-ray drive in my new i5 work station everything is working fine. I suppose this could also be a factor in sounding better. As all things laptop certainly can't be called great.

Robert