XXHighEnd - The Ultra HighEnd Audio Player
February 22, 2019, 05:01:35 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: August 6, 2017 : Phasure Webshop open ! Go to the Shop
Search current board structure only !!  
   Home   Help Search Login Register  
Pages: 1 2 3 4 [5] 6 7 8 9 10
 41 
 on: January 28, 2019, 11:37:45 am 
Started by PeterSt - Last post by Tims
Hi Peter

Thanks for your reply.
Hmmm, I'm not sure I do understand completely  blink Happy.
One last time! For the configuration:
A:[W]B-R, B:[W]B-R
Does this mean current is flowing in W and also in R (because B & R are connected at the pins)? 
And, no current flowing in Y as Y is floating (not connected at the pins)?

Tim


Hi Tim,

No, not 4 screens. Just 3 as the other ^2 cables but with one always connected (fixed) and this is the W(hite). So this part is now not configurable.
Notice that B(lack) is always the connector end.

Quote
and another three screens (B, R & Y) that are not connected to W?

Oh they are, when you configure it to be so. Happy But I suppose that is what you meant anyway.

Best regards,
Peter

 42 
 on: January 28, 2019, 08:50:43 am 
Started by numlog - Last post by PeterSt
Quote
to highlight how specific this is:

In the X3 log file, you see the number 4992 appear twice. That is the number of bytes found for "audio data". And this will be derived wrongly from for now too many possible "wrongness". N.b.: The various players (also XXHighEnd) use all kind of consistency tricks to find missing header data and/or correct wrong header data.

In this case, but only at brief glance, it could be the length of the audio data itself but also the "block align" (summarized : how many bytes are packed into a block of data to form one round of all channels for one logical sample).

Since I am not going to correct this, it could be an idea to convert this to FLAC (XXHighEnd may be able to do this just the same, no matter it won't play it really) to after that convert it back from FLAC (XXHighEnd could do that again for you). Now it may be OK (header data corrected, *if* FLAC was able to make it consistent / workable in the first place).


Kind regards,
Peter

 43 
 on: January 28, 2019, 08:39:07 am 
Started by numlog - Last post by PeterSt

numlog, do you parhaps have a name we can address you with ? actually it is an unwritten rule that people should not be anonymous. And this is merely for recognition (say when it is a year after, etc.). Thanks.


Then first an actually not related remark :

Quote
Since a true need for pre-converted WAVs arose (to avoid copying to OS/XXHE drive for playback),


It may surprise you that this is for several reasons worse then the copying implied otherwise. One of the things is loading speed (from Playlist Area to Unattended Playback). You can watch it yourself by means of the progress of the highlight (on track) bar of the tracks being processed). With WAV it is one by one; with FLAC it is as many in parallel as your processor has cores available.

Peter

 44 
 on: January 28, 2019, 08:32:40 am 
Started by numlog - Last post by PeterSt
Happy

 45 
 on: January 28, 2019, 08:31:28 am 
Started by PeterSt - Last post by PeterSt
Hi Tim,

No, not 4 screens. Just 3 as the other ^2 cables but with one always connected (fixed) and this is the W(hite). So this part is now not configurable.
Notice that B(lack) is always the connector end.

Quote
and another three screens (B, R & Y) that are not connected to W?

Oh they are, when you configure it to be so. Happy But I suppose that is what you meant anyway.

Best regards,
Peter

 46 
 on: January 28, 2019, 08:20:52 am 
Started by numlog - Last post by numlog
not an issue but something very very strange that popped up today and this is the most appropiate place for it.

all WAV files created with Aul converter will not play with wasapi in XXHE no matter what. no error only a short blue flash of the kill engine button

to highlight how specific this is:
  • only aul converter. attached are 2 flac-to-wav conversions from aul converter and another conversion software, freac, of the same source file. I probably changed every setting in aul and still nothing...see if it plays for you (dBpoweramp, foobar wavs also play)
  • only WAV, converting to any other format will play.
  • only XXHE and only wasapi. KS output, ASIO,  HQP/Jriver/foobar w/ wasapi - no issues.
    none of XXHE settings could make it play.
    location does not matter. same folders, different folders, same name, different name,  OS drive or external - nothing.

although strange it isnt the first example of hidden differences between WAVs, the reason of using aul converter in the first place is that the quality of XXHE's internal FLAC to WAV conversion is better than preconverted wavs from freac, which itself is better than foobar wav conversion.
Since a true need for pre-converted WAVs arose (to avoid copying to OS/XXHE drive for playback), I was trying aul converter as a better alternative to freac.


 47 
 on: January 27, 2019, 11:56:01 pm 
Started by numlog - Last post by numlog
just want to add something that might be very important for some.
BIOS settings got wiped today after a hardware change, after changing back all the settings and booting up the sound was not good at all. rebooted into BIOS and there was one setting I didnt disable: CPU SVID support

Disabling SVID sounded better with default CPU setting when testing it way back but according to some post in an overclocking forum SVID  should be disabled specifically when you're using manual core voltage,
its not overriding the settings at least (BIOS still shows the core voltage I set when SVID was enabled) but it critical for good sound.

 48 
 on: January 27, 2019, 10:22:11 pm 
Started by PeterSt - Last post by Tims
Hi Peter

I've changed my setup and now need a decent SPDIF cable to replace the generic RCA cable I'm currently using.
For my greater understanding, does the Blaxius^2 Digital actually have 4 screens:
One inner most screen for carrying the current (call it W) and another three screens (B, R & Y) that are not connected to W?
If the above is correct does it come pre configured with a 'consensus' configuration?

Thanks

Tim



Something else ...


What you see here is the "definitive" version of the Blaxius^2 in Digital fashion. Let's say it is named Blaxius^2-Digital.
The difference with the Blaxius^2 for anlogue is the missing White wire. The annotation as you see it in the picture (the B end assumed the same) would be :

A:[W]B-R, B:[W]B-R

The [W] means that it is internally there all right and can not be avoided. It also means that - unlike the normal Blaxius^2 - it would be allowed to not connect any of the "connectable" wires. This is because the ground return path goes over the fixed (White) shield. It would look like :

A:[W], B:[W]

So, true, the "White"/innermost shield is there by standard for the digital version of the Blaxius^2. This appeared to be necessary for utmost critical applications, like Chord's Hugo M Scaler. Envision two BNC outputs for a dual wire setup to achieve max 768KHz output (each BNC cable being 384 capable), those outputs so close to each other that there's only 1mm space in between the two cables. And now they interfere with each other with the notice that for normal Blaxius^2 there is no configuration possible with 100% shield coverage for the signal wire in the cable. Thus also not when the inner shield (W) is the one in use.

The above mentioned is normally not a problem, but the M Scaler which seems suspect to RFI to begin with (not my own judgment but derived from hot discussions about it elsewhere), now pushes its higher frequency signal (50Mbit/s per cable) through two very close to each other connections, them causing interference with each other. And now the tiniest bit of "irregularity" may cause trouble.

Peter

 49 
 on: January 27, 2019, 02:50:28 am 
Started by Robert - Last post by numlog
Also notice that most DAC's will let themselves "overrule" for the filtering, hence, an e.g. 88.2 will not engage filtering for 44.1 (read : will not roll off under 22.05). This means that "our filtering" will be effective in maximum fashion. But if the DAC does not understand this way of working, then the overruling merely becomes "messing with". And then you will have quite contradictionary filters on top of it all. This is why a DAC actually should be Non Oversampling; now we can guarantee that our filters will be applied for 100% (not messed with even the slightest).
This was really helpful advice, the biggest issue at 44.1 was bass, a lack of definition and extension. it must be as you say because 88.2, like 705.6, fixes this entirely. same benefits with much shorter buffer, along with generally nicer sound (less load?).

 50 
 on: January 26, 2019, 10:26:09 pm 
Started by numlog - Last post by numlog

This is more complicated once you see the relation with XTweaks in XXHighEnd. I guess you do, but just saying ...

Peter
xtweaks is worth mentioning.
Based on the descriptions 'nervous rate', 'provide stable power', 'utilize cores' sound like they should behave the same with CPU clock and voltage changes so I ignored them. There are options for C-states, speedstep and Turbo Boost in BIOS which are disabled, from the descriptions they sound like they could be the equivalent to Utilize core and stable power settings.
 
Balanced load is confusing, based on listening a while ago the low balanced load settings gave better results with default CPU settings. From its description you could assume the lower BL setting would be bad  with heavy underclock/volt, when the CPU peak state is already slow/cold, yet the BL low settings give similarly good results... im not sure I understand BL but some consistency is good, less need to worry about BL interfering the effect of the BIOS tweaks

Pages: 1 2 3 4 [5] 6 7 8 9 10
Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.086 seconds with 10 queries.