mysterious unplayable wav

[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.

[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 :

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

[PeterSt]

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

[numlog]

I understand, you can call me Laurence.

Using a HDD for storage has objectively better SQ (on this system) than a storage SSD or OS SSD. I noticed this with FLACs but that makes no sense, it always the WAV conversion on the OS SSD that you hear.
others on computeraudiophile confirmed HDD are better for storage.
WAVs on the HDD is even better.

flac conversion wasnt able to correct the header data, if that is the problem with the wav.
I dont understand the explanation, but all I was wondering is if you had an explanation.

[PeterSt]

Laurence,

I dont understand the explanation, but all I was wondering is if you had an explanation.

The writer of that software you use puts the wrong data in the header of the file. This data - via via - determines the length to play; Somewhere that is wrong. And apparently FLAC encoding can not even deal with it ... (and if other software can, you / that software is in luck).

Using a HDD for storage has objectively better SQ (on this system) than a storage SSD or OS SSD.

It depends on the SSD, but generally I agree with that. If you search this forum for "SSD" I suppose you run into a bunch of posts dealing with this, over 10 years ago. But YMMV.

The approach is the exact other way than you envision : denote a "Playback Drive" of which you expect it sounds good and imply with it that also the WAV is always copied to that (XXHighEnd takes care of this). Can be a HDD (they all sound different), an other SSD (same), a USB stick, an SD card, ... anything.

Best regards,
Peter

[numlog]

The writer of that software you use puts the wrong data in the header of the file. This data - via via - determines the length to play; Somewhere that is wrong. And apparently FLAC encoding can not even deal with it ... (and if other software can, you / that software is in luck).

much clearer, thanks.

The approach is the exact other way than you envision : denote a "Playback Drive" of which you expect it sounds good and imply with it that also the WAV is always copied to that (XXHighEnd takes care of this). Can be a HDD (they all sound different), an other SSD (same), a USB stick, an SD card, ... anything.

well that was a lot of time wasted being stuck on the idea XXHE should be stored on OS drive, thanks to you a whole lot more time (and hard drive space) has been saved. 

[PeterSt]

well that was a lot of time wasted being stuck on the idea XXHE should be stored on OS drive

Well (if I understand you correctly), XXHE can be stored on the OS drive allright (no reason to avoid that) as long as we see that the location from where the music is played can be anything (but advice is to keep that local although that is not even a hard requirement).

Btw, this smells a little like what I put in my previous post but scratched again : We also have the RAM-OS Disk. That loads the OS into memory, boots from there, and after that you can remove the HDD/SSD. Now nothing can be in the way anywhere. Playback is now "from the XX Drive" which is pure RAM (16GB of RAM is sufficient but 32GB is more convenient). Load the music from the network somewhere ...
But costs 360 euros.

Peter

[numlog]

XXHE can be stored on the OS drive allright

but the the program SQ wont benefit in some way from the faster SSD, like lower latency or the same reason a fast SSD sounds good as an OS drive. i was ignoring PC basics, programs run off RAM 

Laurence

[numlog]

Its been over a month and I only realised now that ''playback drive'' is something that can be denoted in settings.

This was explained in the RAM disk thread, incidently a RAM disk sounds like the simplest and most effective use for a playback drive (if you have capacity to spare).

Using a typical (HDD or SSD) dedicated playback drive im sure has benefits, but inevitably complicates the system.

[PeterSt]

Using a typical (HDD or SSD) dedicated playback drive im sure has benefits, but inevitably complicates the system.

Correct, I'd say. But I don't think that by now the Playback Drive is used any more to imply something with a best sound. The reason to use it changed when time passed ...;

First off, a lot of people indeed use the RAM-OS Disk, or otherwise use an "Mach xx PC" which utilizes that (thus same story).
Next, indeed the playback from a RAM disk emerged more explicitly underway (while this has been possible from day one) with the parameter (Playback Drive) suddenly playing a large role there. Thus indeed, denote a RAM Disk, and you should have the best situation/environment for the better SQ.
Then, what sneaked in along the lines (but which 100% was my target for it !) was the elimination of the possible (or probable) difference between WAV and FLAC. Say that the Playback drive is a specially formatted - but also most specially treated device when written to it - that it acts as a buffer which rules out the difference between WAV and FLAC. However, the sheer fact of this special treatment turned into a life of its own, and the difference between WAV and FLAC was not talked about any more (which did not happen really in this forum anyway, but elsewhere it did massively).

Lastly, the usage of two PC's, one to hold the music (Music Server PC) and one to play the audio (Audio PC) eliminated the use case of the Playback Drive, because the Alwas Copy to XX Drive should be in order in that situation. This is so the LAN can be shut off during playback.

And so tbh I myself never bothered about the Playback Drive any more, since what ... 6 years at least ?
If you use one PC for both storage and playback, it's a whole different world. But you shouldn't do that ... (all present in the Audio PC - or connected to it for that matter, deteriorates).

Regards,
Peter

[numlog]

Ok I understand, the server PC you describe sounds like NAS with XXHE on the audio PC,
usually (or sometimes) the audio PC is only a DAC interface and network interface to server... that isnt preferred here?

I do use single PC, using a server seems like the way forward but improving things on single PC is still possible, sometimes in undiscovered ways, it can be interesting.

Using the RAM disk for playback since was an improvement only with a strange difference. Previously the best sound was achieved with XXHE installed to storage HDD, assumed to be benefit of local FLAC decompression.
Now with RAM disk for playback, XXHE installed on the OS drive/SSD is now better but only with the HDD still used as storage.

you also mention this in ramdisk thread I notice, the install location matters, even though software runs from RAM (I guess at this point it shouldnt be a surprise)