Jump to content


  • Content Count

  • Joined

  • Last visited

About tailspn

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes. NativeDSD converts DSD64, DSD128, DSD256, and DSD512, as well as a DXD FLAC individually, only from a labels DXD (PCM 352.8KHz 24 or 32 bit) edited master (regardless of whether the album was DSD or DXD recorded). The DSD64, DSD128 and DSD256 deliverables are all first generation modulations from the DXD edited master, created through Merging Album Publishing. The DSD512, also a first generation modulation, is created from the same DXD edited master through HQPlayer Pro. The exception is the very small number of label projects (Yarlung, Eudora, Just Listen etc.) who send DSD edited masters in the original recorded DSD bit rate, which have not been post processed in PCM (DXD). I create the missing bitrate DSD deliverable bitrates using HQP Pro. While these are technically second generation modulations (for the other than delivered DSD master), it's a process less injurious IMO to a DSD > DXD > DSD conversion sequence. The deliverable DSD bitrate used to record is actually the session master. Tom
  2. Yes, that is a valid route. One additional bit of information that may be of interest; the FLAC we produce is limited by the format to 24 bit, where as the WAV edited master I receive is typically 32 bit. When the recording is converted initially to DXD, it's essentially 24 bit linear. If it's just edited, the results are still 24 bit, but can be rendered out as either a 24 or 32 bit WAV. If however, there's post process sweetening like EQ, mic channel balance and mixing, and/or effects processing, the resulting file is automatically computed in 32 bit resolution. Merging Album Publishing automatically uses the DXD WAV resolution provided in the edited master to produce the individual DSD bitrate modulations, and truncates the bit depth to produce the 24 bit deliverable FLAC. I produce a 32 bit WAV in order to produce the DSD512 using HQPlayer Pro. Its not yet clear if there's a sufficient market for the 32 bit DXD WAV tracks to offset the storage costs, but it's a possibility. Tom
  3. We don't with anything we master. However, several labels provide us already mastered recordings in multiple DSD bit rates, for which we simply tag and upload to our delivery server. They all state the multiple DSD bit rates were produced in separate modulations. This is realistic in that most all DSD recording labels use Merging's Album Publishing, which performs DXD > DSD conversions sequentially. Tom
  4. It's much more than marketing (although we could use some), they're new releases. They're original first generation modulations at higher bit rates from the original DXD edited masters that produced the DSD64 downloads and SACD's. The Pentatone recordings, like the overwhelming majority of other label's original DSD recordings, are recorded in a variety of DSD bit rates, but are post produced in 352.8KHz PCM (DXD). That decimation and conversion process removes the uncorrelated modulation noise, and converts the digital valueless DSD bit stream into samples of binary digital values. That's a requirement with currently available Digital Audio Workstations (DAWs) to do any post processing other than simple edits. Up to now, Pentatone's digital releases were DSD64 only. NativeDSD has acquired the original DXD edited masters from Pentatone, and is producing all the DSD bit rates, plus a DXD FLAC copy from those DXD edited masters. This is very different than remodulating the currently available DSD64 modulation (which was also produced from the DXD edited master), to a higher DSD bit rate. As an aside, there's also no such thing of "upsampling DSD", for there are no digital samples in a DSD bit stream. It can only be modulated again, or converted back to PCM). The shortfall of remodulating a DSD64 to higher bit rates is that it produces a second generation DSD modulation with the original modulation noise added to the modulation noise of new higher bitrate modulation noise. The exception to this is a conversion tool like HQPlayer, that filters the lower noise bitrate prior to remodulation. Good, but not as pure as a first generation modulation from the original PCM master source. That's what NativeDSD and Pentatone are providing with these new releases. The advantage of higher DSD bit rate releases (while there's no additional audio content information), is that DAC's/players perform better at higher bit rates due to gentler/more Gaussian shaped reconstruction filtering. Tom
  5. tailspn

    HQ Player

    If 100ms is 10Hz, then 50ms is 20HZ.
  6. Hi Matt I agree with the first part of your sentence as applied to the communications within Hapi/Hours, and wonder if you meant the second part as written. The second part; "at least with Pyramix" should read "except with Pyramix". Pyramix; a software Digital Work Station (DAW), is both a file handling and management system, and a digital signal processing system. That's what all the format conversion parts and plug-ins do. However, the DA8 or DA8P DAC boards actual DAC stage is a combination of two primary components; a DSP processor and separate ESS9028 DAC chip. It's my understanding only the Sigma-Delta Modulator output stage of the 9028 is used, and the separate DSP processor performs the functions of the onboard dsp processor of a 9028/9038 chip, with Merging's proprietary algorithms. https://www.merging.com/products/interfaces/specifications#d-a8-d-a8-p-option-card The DSP is the larger of the two chips. Tom
  7. That would make more functional sense, although almost twice as expensive. Additionally, as I understand from Jussi Laako, he now working to get Merging Hapi verified for 4.0.1.
  8. Well, my only suggestion is don't wear out your welcome. They're unbelievably busy with this and future roll-outs, that if you do get an answer of this level of technical detail, aimed at an application the product is not marketed towards, you'll probably only get one bite of the apple. I'd shy away from asking general interest questions, and focus on the one most important to you
  9. Sounds like a plan! I hope you receive from Merging the answers to your questions that you like. But why do you care if you're front ending Anubis with HQPlayer tightly coupled? The PCM anything > DSD256 will be accomplished in HQPlayer, and Anubis will only ever see DSD256. In your position, I'd be more interested in knowing from Merging the specifics of what, if anything, they do with a DSD256 imputed bit stream. I'm only experienced with what Merging does under Pyramix, and that's a straight playout. With the recordings I make in DSD256, they're so noticeably more realistic from not having to do DSD > DXD/PCM > DSD conversions (due to the non loss of low level spatial cues resulting from DSD > DXD > DSD conversions), that I never question how they do it.
  10. The 9028 chip runs at the bit clock rate of the DSD content bitrate being played out through it. I know of no up bitrate remodulation of any DSD content associated with the DAC portion. That doesn't mean it's not being done, it's just that I don't know. Also, only Merging can answer what multiplier rates, if any, they use in their DSP processor and conversion algorithm, converting PCM to the PDM format fed to the 9028 chip. A question for you and Matt; what will you do with a Anubis if you purchase one? It's a three functional device; a 4 channel PCM and DSD recorder, a 6 channel PCM and DSD player (but intended as a 2 channel player with the odd mix of connections used to serve the DAC outputs), and a networked controller of some degree for other compatible Ravenna/AES67 networked devices. In other words, it's a Merging family recording tool. As a DAC only use, I'm sure they're equal less expensive products available. Anubis, as the other Hapi/Hours products in the line, IMO, only shines when used in conjunction with Pyramix DAW software for editing and post production of recorded material. Thanks! Tom
  11. Sorry for any confusion. Merging certainly does not funnel everything/anything (other than DSD64) to DSD64 for feeding the 9028. My analogy is based on how merging converts the various DSD rates to DXD (352.8KHz/24/32 bit) for post processing, and serves only as a basis of how they "may" convert PCM to DSD served to the 9028. Without a logic analyzer, and the desire to reverse engineer their DA8P board, any conjecture of the kind of detail being asked about is just that; conjecture. The ESS9028/38 SDM is specified to operate at somewhat above 12MHz, and I believe has been proven to operate at almost twice that in support of DSD512. I take it on faith that merging uses every bit of the chips bandwidth for each PCM wordstream conversion they do in their off chip DSP.
  12. I suspect the information you're asking for may be proprietary to their process, The best person to ask is Dominique Brulhart, VP Engineering at [email protected] My understanding of their conversion processes is from working backwards from the decimation rate Merging uses from DSD64 to DXD, which is 1/8X. For DSD128 and DSD256 they use a two step process so as not to exceed a 8X reduction. Frankly, questions like these are not asked of them very often, for there are so many other issues much more relevant to the recording, playing out and monitoring with their professional products. But they entered the audiophile/consumer market with their NADAC series, so yours is a reasonable technical question.
  13. "What sample rate (at 1 bit) do Merging have this neighbouring processor converting to, before the 9028 DAC chip?" "DSD256?" To the best of my knowledge, the DSD bitrate presented, and for PCM, 8X the sample rate of 352.8 or 384KHz. The multiplier may be higher for lower PCM sample rates. I'd suggest asking Merging for the most accurate answer to your question. Tom
  14. The "why not AKM for both functions" is a good question for Merging. But please bear in mind that Merging uses only the SDM output conversion part of the 9028 chip, which is the smallest percentage of ESS's design. The format conversions, and other magic, are performed by their own software processes in the neighboring processor. By the time digital content gets to the 9028, it's all Pulse Density Modulation (DSD). That's also one of reasons they do no use the more expensive 9038, whose richer front end conversion processes they don't use. Jussi Laako may want to chime in here, with his wealth of knowledge of these chip architectures.
  15. Several years ago, an engineer and DAC company owner who everyone here would recognize immediately, said that paralleling DAC channels was one of the stupidest ideas he'd ever heard. It does have the benefit of reducing the noise floor by 3dB per channel pairing theoretically (actually less because noise is not completely random in a bounded frequency response system), at the expense of smearing the sound due to timing differences in each of the parallel channels. DAC's today, which approach a -130dB noise floor, hardly need another 6+dB of noise reduction. I know it's a very salable spec feature today, but just sayin
  • Create New...