Zaphod Beeblebrox

Not right now, but perhaps after release of v7.

Not on release but it could. It will depend on the demand for native version, as porting the high-performance multi-precision library to ARM is significant effort, the current library for DSD on ARM even in emulation already closes the gap (between native and emulation) and only about 25 - 30% gain can be expected. On the other hand, for PCM the expected improvement is about 50%.

Still work in progress, but I thought I will share some screenshots. Themes: The UI will be the same on Mac and Windows, this (screenshots) is the Dark theme, but it will also be available in light theme (Based on what the system theme is). Organized: Though the processing will be the same, I have reorganized the UI to make it more logical and easier to access. Drag/Drop: You will be drag/drop folders and files (input, output, temp etc.) in addition to browsing to the folder/file location or manually entering. I have put in additional checks to prevent nested input/output folders. File formats: Additional file format support: In addition to be able to write PCM as Wav, FLAC and WavPack, you will be able to write write it as uncompressed Wav RF64 format that does not have the 4GB limit. In addition to DSD, I will add support for WavPack DSD. Virtual Memory: The UI will now report the available virtual memory taking the guess work on whether you have set it up right. If a track may exceed the available virtual memory (RAM + page file), it will skip the track. DAC Presets: To make it easier to get started, PGGB will come preloaded with DAC presets for DACS PGGB has been tested with. You can select the DAC preset for your DAC to see my suggested optimal settings. Of course, you can alter and save to create your own presets. Configurations: You will be able to export or import configurations (to make it easier to share with others) Other functionalities and SQ: Under the hood PGGB will remain the same, almost all previous functionalities will be kept, but your cheese may have been moved. Matlab: No more Matlab or having to install Matlab runtime, launching will be faster and it will save about 4GB of memory footprint. Plots: Since I have moved away from Matlab, you will lose the ability to analyze from within PGGB, but you can still do that with the free tool RASA. I may add it in future. Linux: Possible Linux support in the future.

Was this the case with any wav files or just PGGB wav files? Also wonder how much this a function of size of the file is.

I plan Is to introduce a 108 bit option for PCM that would be nearly as fast as 64bits, my hope is for the Foobar plugin to also get that upgrade for real-time PCM upsampling. No ETA though. The change will coincide with a major overhaul to PGGB UI, I will be moving away from Matlab to a more modern cross platform interface. I will post some preview screenshots when it is more mature. This move, In the long term, would allow me to incorporate real-time upsampling for streamed content.

If you like 256bit + dither, you should try 64bit + dither and also 128bit + dither. Without noise shaping, there is very little justification to do higher precision. With R2R DACs the reason to do noise shaping is two folds. 1. To linearize the last few bits 2. To take advantage of high precision computing IMHO you will be giving up even more.

My response was purely from digital a signal processing perspective on whether the DAC will benifit from DSD upsampling. Every aspect of the DAC design matters, so we have to wait to see if it actually sounds good.

Based on the measurements Topping has posted, PCM path is not R2R, it is sigma delta, what is not clear is if DSD and PCM have separate paths and how PCM upsampling is implemented. Yes, likely a good candidate for DSD256 or DSD512.

The DSD portion of the DAC looks like it will be allow 1-bit DSD through without any processing and convert it directly to analog using a 16 element analog FIR. It is less clear on what would happen to PCM, they do not state if it is a R2R or a chip DAC, oversampling is very likely involved. Given it allows PEQ, they do have a DSP built in.

It is a bit early to say (pun intended) but looks promising as a DAC for DSD upsampling. The marketing material is vague on details, so best to see some measurements and analysis.

start_pts and start_time are not part of metadata, it is how ffprobe presents the streams. There is no way to add that information within what the wav format allows. Here is an example ffprobe results from a .wav that was ripped from CD but was not upsampled or otherwise altered. I suspect either you will face this issue with all .wav files or it may be related specifically to the larger file size. @kennyb123 Have you faced similar issues with mojo/poly (assuming you have poly)?

Make sure you use the one in your install folder as a template and yes, the name needs to be the same. DM or email me the json and the settings you intend to use, I can verify it is correct for you.

Yes, PGGB has aways had the ability to customize processing at the folder level for power users and uses pggb_256.json, you should find a copy in your installed folder, but you have to be very careful using it as it lets you control all the settings (and the risk is you may inadvertently change a setting that you did not intend to), it includes comments and values each setting takes including gain. You can drop the json file either into the folder or at the parent folder (it would apply the settings to all tracks in that folder and sub folders). You can have multiple such json files each customized for a set of folders.

Good to know, though normalizing should take care of that, the APIs that read 64bit wav files do not anticipate values > 1 and would have most likely clipped.

Does it happen with a few tracks or all tracks? you could try 128 bit precision instead and that would be faster. One of the reasons I did not do RF64 was Roon does not support it. Does reaper support it?