my wavelab 6 supports max 384K pcm - that’s cool and i use it for high speed dubbing
the 11.2 has many new gimmicks but pcm is still at 384K - how comes?
nowadays 1536K converters exist already - how do i make such files for testing the converters?
the WL slogan says: High-end mastering and editing for digital distribution
soo, how does one reach high-end samplerate with it? 
Which converters support higher sample rates than 384kHz?
i’m currently testing akm ak4499 series and rohm bd34302ekv - these can go quadruple 384
and these are older which go at least twice 384 (can’t swear by all of them - that’s a list from the net):
Holo Spring 2
Holo May
Denafrips Terminator
Denafrips Terminator +
Chord DAVE
Chord Mojo
Chord Hugo2
Chord Hugo TT2
Chord Qutest
Topping E50S
Topping D30
Topping D90
iFi Micro USB
iFi Pro iDSD
RME ADI-2 DAC FS
Topping D50
SMSL SU-8
SMSL SU-9
SMSL M100/M200/M400/M500
SMSL IQ
Topping NX4
Gustard DAC-X16
Topping D70
CJH
and there are more…
so yeah, stuff that exceeds 384K PCM exists for almost 10 years already
and dsd is also around and been for a long time - also getting ignored
i get that one can’t edit dsd but import and export would be good
and PCM up-to-date rates is no question 
When even the “Sanken CO-100K” is not enough…
hehe, i’m really not sure if that sanken is enough - most likely, in most daily situations u67 would trump it .
as my takeaway of the high samplerates would be disabled filtering and oversampling of those chips - they allow it at these rates.
and a quick search revealed that reaper already supports 768 - it’s formidable how they manage to catch up and eventually outrun the dinosaurs of daw world yet pricing is so low compared.
It wouldn’t be a problem for WaveLab to support 768kHz or higher. It’s just a number that doesn’t change anything from WaveLab’s point of view, but it multiplies CPU consumption and significantly increases memory requirements (which can also cause slower rendering due to CPU caching issues).
If this has never been implemented, it’s because the benefits are not apparent. The higher the sampling rate, the slower the rendering workflows become. All this to process frequencies that are not audible to humans.
All the professionals I have spoken with, for whom time is precious (an hour of work in a studio has a price! ), are satisfied with 96kHz. It’s a pragmatic choice.
Rendering at 768kHz takes at least 8 times longer than at 96kHz. This is the first time that I think this topic is addressed on this forum, which reflects that very few users must be interested.
Well, there is some use for ultrasonics, though.
Doubling sample rates doubles the number of samples for the same time.
…whenever I see this view in WL, I wish, the scalling of the frequency-axis would be with nice numbers like 100, 200, 500, 1000, 2000, 5000 , 10000… you get the idea.
The related numbers are displayed below according to cursor position.
Yes, that would be nice but then, the markings would move up and down when changing Frequency Scale and FFT Bands.
In the actual situation, markings are fixed and relative numbers change accordingly with those settings.
It’s working fine in SL (and lots of other programs, though)
But, year, WL is specical… got it.
Simplicity might not be first priority here?
I agree. The design was to have ticks equally spaced, but I agree, it’s not the best solution. It needs to be changed sometime.
exactly! if it’s not a problem / big deal of programming / why not adding samplerates to cover at least existing hardware, i’m not saying you should do some rates that are unplayable by anything 
at times of 32 cores at 5+GHz and even non-workstation pc’s memory slots accepting at least 128GB of RAM (except for lowest end or super compact machines)
and times of simultaneous encoding of 8К h265 streams i don’t think that would be seen as extravagant capability hehe.
i agree that 96K is very enough for sound capture and playback and i also agree that WL 6 is more than enough for wave editing duties - i bought WL 11.2 just for the plugin (in)compatibilities, that’s all.
yet somehow stuff moves on and we have new plugin standards (not that anyone asked or really needed), and we also have these new D/A chips which go to 1536K and currently i know that HQPlayer 4 Pro supports these formats
and for fun - there are cassette duplicating machines which run at x16 which requires 705K samplerate. i run a 8x one that’s happy with 352K - hence WL is enough for that…
i was surprised to find out that even in the nineties master control units of these duplicators sported dsd style 1MHz+ conversion – https://www.tapeheads.net/threads/cassette-duplicator-quality.16956/
There are tasks, that can not be parallelized in principle. I believe, that soundmanipulations via serial plugins (one after the other) is such a task and this therefore relies on a fast single processor core.
No matter how much ram or how many cores are available, the time of single execution is the bottleneck here.
If I am in error here, please let me know.
mp3 encoder in WL11.2 works WAY faster than in WL6 on same machine and makes more heat - that suggests optimisations
as for serial plugins - each of them might use different cores and hence finish sooner too!
it’s not that they pass entire sausage one after another - they work in short blocks - so by the time first plugin has done with first block the second can start working on it and the first can take another block - so both plugins on separate cores can be active at the same time, eating same track just at different places at given moment… and overall speed would depend on the slowest performing plugin then.
for me it’s always a dsp card or an outboard plug-in…
