1067
|
Ultimate Audio Playback / XXHighEnd Support / Re: MQA decoding issue
|
on: March 15, 2018, 08:15:54 pm
|
ZH, I just wonder that once a MQA capable DAC is used via USB, will MQA track continue to undergo second stage "unfolding" before it becomes analog signal? a. When played via XXHighEnd, no filtering is allowed and also volume must be at -0dBFS. Then it will work. b. It is generally regarded that any second or more unfold is an upsampling step per means of "Meridian" (MQA) filtering. Ad b. If you like that filtering (which is told to adapt to your DAC), then OK. But if you don't like it - for example because you like Arc Prediction better - then your MQA DAC is a waste. Chances are small that you coincidentally like the MQA upsampling/filtering but theoretically these chances are as small as you like XXHighEnd's upsampling/filtering. Both are very different though. The money involved could be a bit different. Haha. And I try to make the best of it (but I may not be alone on that one). Kind regards, Peter PS: Ask as much as you like.
|
|
|
1068
|
Ultimate Audio Playback / Playback Tweaks and Source related subjects / Re: Trying w10 on my old PC
|
on: March 15, 2018, 06:27:59 pm
|
I cannot use straight contiguous, not even 0,19mb (silly!) Not sure whether it helps, but be sure to start a few seconds of playback the soonest after booting. It's probably too late already, but the more seconds you wait, the more "contiguous" memory will be eaten by other processes, scattering everything. Side note : I recall that the memory reserved for this is at block boundaries. So once you are under that limit (of 2MB or 4MB) making the SFS smaller does not help any more (SQ will still change though). not even 0,19mb (silly!) Not that you can work with it, but notice that this 0.19 example number, it without unit. So it is not MB or something. In the far end memory is implied surely, but it is merely about a "response". So it implies memory alright (the smaller the number the lesser the memory used), but there's matters involved like bit depth and sampling rate and sort of buffer and Q1 size and ... It can not be explained (and I dont want to ). Peter
|
|
|
1069
|
Ultimate Audio Playback / XXHighEnd Support / Re: MQA decoding issue
|
on: March 15, 2018, 06:19:08 pm
|
Also is there a way to resume a partially prepared alubum other than deleting everything and starting afresh?
Hi, I assume you want this because of that other issue : When I select an album to be prepared, only one of the tracks in album will be prepared. ... and when this is solved you won't need to Prepare a remainder, right ? OK : I actually am not sure what you mean. There is no way to Prepare an album partly only, unless you just play one track of it in Attended Mode. But well, let's say that you may be doing something which is not expected by me. So what I do myself : - Search for the album in Tidal; - Prepare it; - Play it now or later. There's no way that you will end up with a halfly Prepared album unless something goes wrong during the process. And then still : When the Prepare stage is interrupted (which is similar to Prepare one track only) then if you'd Prepare it the next time in full, it will Prepare the remainder. Mind you, this is all done in the "TT" structure (see Search button encryption) amd when done, Move that to the Tidal structure (again see Search Button). Thus, it is *not* the intention that you apply this Move when you have Prepared one (or a few) tracks only. I am not sure what would happen, but I am quite sure unexpected things will happen just because I did not make it to behave like that. I think that there's one means to Prepare an album only partly : Play a track of it while the album was not prepated explicitly. So be sure you understand where that Explicit Prepare sits, look below (Library Area is active there). You can still do that after you have played on track before explicit Prepare, but don't move to the Tidal structure first. Let me know if you understand anything of this post because I feel we may not be talking about the same things. This is also related to this : My current workaround is to play whole album in unattended mode. Once it read all tracks are read by XXHE, they are all prepared even without playing through all tracks in album. I understand that. But what happens in that case is that you play the tracks subsequently (but in one go) which causes XXHighEnd to subsequently decode them. This wasn't even explicitly made like/for that but I can imagine it works (but maybe things go wrong when you don't play the whole album like this, and the next time it finds an inconsistent situation and causes you to do all over in order to get it right. So the more I think about it, the more I feel that you do not use the option I show below. And notice that you can do a 100 at the same time, if you want (just select more and then perform the Prepare function). Lastly do notice that this Preparing is unrelated to the MQA decoding. That always happens in real time; ot per track when paying Attendedly, or for the whole album in parallel when you use Unattended and per as many in parallel as you have processor cores. I think what you imply by your means of playback (which starts with dragging in the UNPrepared tracks) is that per track the track will be Prepared and MQA Decoded after each other and that again in parallel when done in Unattended Mode. No, I certainly did not make that, but I can imagine that it works (to some degree). Regards, Peter
|
|
|
1070
|
Ultimate Audio Playback / XXHighEnd Support / Re: Play back stoppage due to crack detection
|
on: March 15, 2018, 05:50:28 pm
|
Hello Shreekant,
Good question !
First off, at this moment (in 2.09) the Crack Detection is set too tight. So it will trip more (present the Crack Detect message and stop) than desired. Still it is justified actually always, as far as I can see myself. Anyway, in 2.10 it will be more "loose".
Despite the above, what you encounter is the real "wrong rip" and therefore the crackling you observe. This is harmless ! However :
With Crack Detection switched off, you will be subject now to *my* possible anomalies in the software. Thus, if something goes wrong in XXHighEnd (by sheer coincidental happenings) you windows will go out, so to speak. Thus this is what Crack Detection is for. Solution in your case of hearing that crackling :
Get a good rip. Thus, this is definitely wrong, unless the crackling belongs in the music (but then you would recognize is). The solution is thus NOT to deactivate Crack Detection. So please let it be on for your own comfort (and windows).
If you experience the tripping of the Crack Detect mechanism in relatively many albums, please investigate your ripping workflow or source(s) of your albums.
Don't hesitate to ask more when needed, Kind regards, Peter
|
|
|
1071
|
Ultimate Audio Playback / Music Storage and convenient playback / Re: No coverart with NAS
|
on: March 14, 2018, 04:38:07 pm
|
& I can’t open the image folder. Yeah, well, wait ... So you have a separate folder under the music files folder with the Coveart files, right ? This makes it a little bit more logic to me. So now it is a complete folder you don't have access to which really is something different as a few image files in the midst of files ending at .flac. Do you know the source of this (these) particular example ? No need to tell it in the open, but you yourself can maybe recognize that a group of albums from an other source doesn't show the exhibit. Of course it already starts with that separate folder for the images which could be called "rare" or at least not a standard (not that there is a standard for these things, but ...). Peter
|
|
|
1072
|
Ultimate Audio Playback / XXHighEnd Support / Re: Safely remove hardware can’t be found
|
on: March 14, 2018, 04:32:49 pm
|
the OS getting corrupt a week or so back, I was just wondering if it was due to my just pulling out the drive. Of course I know now that wasn’t the reason. Ah ... Well, this is a bit tricky, because as said, you could have accessed the SSD anyway but per explicit means (you'd need to do something with Drive D: in that case). If you don't recognize anything of this, then I'd say it has been coincidence and an accident. A rare one though. Regards, Peter
|
|
|
1073
|
Ultimate Audio Playback / Music Storage and convenient playback / Re: No coverart with NAS
|
on: March 14, 2018, 03:17:31 pm
|
Arvind, then I would blame Windows 10 (for its specific Build you are using - probably 14393.0) in combination with your NAS. What about trying to find drivers for it (for Windows 10) ? Remember, if you can find them do not forget to install them under Normal OS BASE. Also a small thingy many people don't know : The ".0" versions of the W10 OS do not contain third party drivers (or as few of them as possible). If I can be of any assistance somehow, let me know. I think eventually it will start to work (I feel you are close already). One more thing : Nope, can’t see cover art in normal os mode either with FLAC files. Re-reading that, I may wonder what you actually say there. I mean, a FLAC file is completely unrelated to an image file which coincidentally is in the same folder. But maybe my yesterday'd question did not come across as intended : Go to the Audio PC, Start Explorer, locate the folder of concern on the Music Server PC - observe the image file(s) in the folder(s) containing FLAC files which don't show the Coverart in XXHighEnd. I did thus NOT mean to use XXHighEnd for this "test". Peter
|
|
|
1074
|
Ultimate Audio Playback / XXHighEnd Support / Re: Safely remove hardware can’t be found
|
on: March 14, 2018, 03:08:57 pm
|
Hi Arvind,
Well well, you ask that pretty quick, right ? ... after a year or so ... Maybe yoy never rebooted. haha
No. This is not needed. You can just remove it. This is a bit different when you start accessing it via Drive D: ... for which you normally have no reason. However, access another OS via "Attaching" is and Drive X:, also goes with the procedure to de-attach it. This is your "eject".
The icon is not there because of MinOS in combination with Windows 10 - 14393.0. Say similar to the Taskbar mostly not working.
Kind regards and very good that you asked ! Peter
|
|
|
1075
|
Ultimate Audio Playback / Music Storage and convenient playback / Re: No coverart with NAS
|
on: March 13, 2018, 04:59:56 pm
|
OK Arvind, so that is the problem. A mere problem is that this is not related to anything I do, obviously. Also it is really difficuly to help as apparently this is a "NAS" (OS) thing. So that it could be something like that became slowly clear to me (finally) but how to approach the solution ... no idea.
For your, and Richard too ! it would be the best to Google yourself for what you see happening and what the solution could be. And oh ... what about trying it in Normal OS briefly ? (I know, this is not really "briefly" (I would hate it)) Maybe it is some service which should run for this, but doesn't. So if it works in Normal OS we will be a giant step further ...
Best regards, Peter
|
|
|
1077
|
Ultimate Audio Playback / XXHighEnd Support / Re: MQA decoding issue
|
on: March 13, 2018, 06:19:46 am
|
Maybe something else for hopefully better understanding : When I look into the ID-tags of these flac files And who made these files ? I can assure you that in the situations I make the files myself there will be no such tag anywhere. So, some stupid softare put that in (in this cace on the Tidal side) and really nothing is using it. It is thus redundant data BUT you found it and use it (against yourself or something, haha). Peter
|
|
|
1078
|
Ultimate Audio Playback / Playback Tweaks and Source related subjects / Re: Trying w10 on my old PC
|
on: March 13, 2018, 06:14:03 am
|
It is quite astonishing, though, how just using RDC causes out of memory errors at a rate 20 times more than when using the computer directly. I think it is not so astonishing. This is because RDC does not use the video card's RAM in the Audio PC. It uses normal memory instead. ... which is a super good thing because now you can remove the video card, which these days is almost a requirement for good sound. Peter
|
|
|
1079
|
Ultimate Audio Playback / XXHighEnd Support / Re: MQA decoding issue
|
on: March 13, 2018, 06:07:24 am
|
Hey Richard, I cannot play these files with my audio PC. What does this mean ? Please always try to qualify the hapening and envision what I must do with it without that qualification. I say it more often : nothing goes without message, so ... if it would for real I need the explicit remark like "just nothing happens". So what is literally going on in this case ? When I look into the ID-tags of these flac files, I can see that the tag ORIGINALSAMPLERATE (44100 or 48000) corresponds with the audio property "sample rate", which is always the same for these wELL working MQA tracks. No, no, triple NO. Nothings is working well when one of the others does not "work" at all (but see below). You just can't know by this statement alone, which besides, is ILLEGAL. So mind you, it is your own thought idea of how things should work. You never read those for me. Never adhere your own ideas about matters, or you will end up nowhere with it, OK ? Now : the tag ORIGINALSAMPLERATE has the value 96000, what seems to be correct. But the sample rate of these flac files is 48KHz only. It should be 96KHz too, as I believe. Why ?? Because I explicitly told you that nothing is decoded in the file you obtained and can observe on your NAS etc., or on your Audio PC for that matter ? So all you just did is give yourself an argument to so-called "know" that it does not work. You just did this two times : 1. When you see a 44.1 or 48 file you are sure it is OK (but PeterSt tells you that you can not tell by that means); 2. When you see a 96 file (btw, also by your own means) you glance at a 48 number elsewhere, and state it thus does not work. Both observations are explicitly wrong. This time I am not going to explain further, but leave it to you to come up with other observations which testify that it does not work. I have seen nothing so far (but I did not read back into the whole topic). So your hint is that you don't have proof so far, while for 100% sure and the most clear, you can see whether it works or not. Never try to listen whether it does. Find all the Release Notes about it. OK ? And please be aware of the fact that I am not saying at all that it works for you. Maybe it does, maybe it doesn't. I just can't tell (at all) by your means of expressing about it. Now let's get it to work ... Peter
|
|
|
1080
|
Ultimate Audio Playback / Music Storage and convenient playback / Re: No coverart with NAS
|
on: March 13, 2018, 05:50:26 am
|
Thank you very much, Arvind.
See below; this is the structure on my Stealth where the Coverart is stored per album, which also can be a Gallery like in my case here. It is stored there per Unattended Playback session. Watch out : with a new (Unattended) Playback session the contents is deleted from of the "1" sub folder and replaced with the new required Coverart for the Unattended Playback session. When XXHighEnd is just quit (no Playback) the contents is deleted as well.
What is different for the Coverart when you play from your NAS ? Better : When you comprise the Playlist Area of mixed NAS and attached HDD, what do you see ? This counts for FLAC files, but you already know that WAV does work. So what do you see for WAV vs. FLAC with a mixed Playlist of FLAC and WAV from the NAS ?
When I started this post I suddenly thought of rights. So the rights of your NAS could be different for FLAC and WAV folders, but which expresses through the JPEG files ?? Seems odd, but something like that could be in order. Regarding this, might you just see the Coverart files in all cases, can you actually open them on the Audio PC ?
To be sure, the sequence : - Start Playback; - Bring up XXHighEnd (Playback is allowed to be stopped); - Observe folders.
Apologies for the super late responding; I was busy with something else yesterday. Best regards, Peter
|
|
|
|