Jump to content

Jay-dub

  • Posts

    231
  • Joined

  • Last visited

  • Country

    United States

Retained

  • Member Title
    Sophomore Member

Recent Profile Visitors

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

  1. I am especially interested in digital filters for recordings made with the Sony PCM1610, PCM1630, F1, and the Apogee filters that were installed aftermarket into certain PCM1610 units starting around 1986. These older units used analog antialiasing filters, which could not be made phase-linear, and in some cases applied rather extreme "phase distortion" (phase delays to the very highest frequencies only). Digital recording units manufactured after around 1990 generally oversample and use a digital filter to prevent aliasing when downsampling to 44.1 kHz. These digital antialiasing filters, more often than not, are phase linear (symmetrical impulse response), and that is the sound I am accustomed to. If I process an old recording with a matching filter, then the net result would be as if the original recording had been made with a phase-linear antialiasing filter. The appropriate digital filter should be straightforward to generate if we can find step-response data from these ADC's Currently, when I listen to one of these old recordings, I put them through a lowpass filter to take out the the frequencies that are most affected by phase distortion (typical choice: 16kHz passband, 19kHz stopband). With phase compensation filters, I would listen with a couple more kilohertz of bandwidth.
  2. It looks like they give an extra grace period of maybe 24 hours after that. The Sibelius is still on sale. Also, if you need time to decide if you want an album, you can put it in your cart, and it will remain there at the discounted price (as long as your browser remains logged in) even after the price on the website goes back up.
  3. There were a few recordings (from the 2002-2004 period) that were originally 20/44.1, and were padded to 24 bits for eClassical. 24/44.1 was their dominant recording format from roughly 2005-2011, so there are still about as many albums in the BIS catalog in that format as there are 24/96. Besides several recordings in 24/88.2, there are also a few in 24/48, but I don't think either of those were ever the label's preferred recording format. I've only once downloaded a BIS recording from eClassical that appeared to be upsampled: the first Schumann violin sonata (with Wallin). The other sonatas on the album clearly have high bandwidth, and are not upsampled. I don't know if anybody cares, but for older BIS albums the files on eClassical are not normally bit-for-bit with the original CD. Most of them (up to the late nineties) were recorded with preemphasis, and that was true of the digital files when I first started using eClassical. Sometime around the end of 2013, the files were replaced. Deemphasis had been applied, and they'd been requantized to 16-bit.
  4. Does this mean that with iOS 11, I can copy a 24/96 ALAC from my iTunes on my computer to the Apple Music app on my phone, and then play it bit-perfect (using the Apple Camera Adapter) from my phone to a USB DAC? If so, awesome! Plug-and-play 24/96 without cumbersome equipment or exotic software at almost every house I'll visit, provided it has a reasonably modern stereo – even if the owner has no experience of hi-res audio.
  5. There are other possibilities. Maybe they considered ways of splitting the signal to two separate loads and decided (rightly or wrongly) that any of them would either compromise sound quality or introduce a vulnerability. Maybe an order came from the business office that this DAC was not to have signal-splitting functionality. I must say I find your presence on this forum very strange. One post to advertise a streaming event, and then two years later you came back to necropost this topic (?!) You are, I presume, the Groot who has made a number of recordings for Pentatone. I'm a fan of the surround mixes but not always of the stereo versions. (Orchestral balances often seem a little off.) Welcome to the community, Erdo, but if you want to use this forum as a place to make announcements and pronouncements, I do recommend participating. Reply to some active threads, and get to know some of the more active members.
  6. My mid-2013 Macbook Air goes up to 96kHz sampling, but the thing is its builtin analog lowpass kicks in right above 20kHz, so it doesn't have the bandwidth you'd expect based on the sampling rate. The benefit of playing 96kHz files on that headphone jack is extremely marginal, much smaller than on an outboard DAC with full bandwidth. You might say that limiting the playback sample rate to 48kHz is a more honest approach than supporting higher rates while incorporating a design that negates their advantages.
  7. You can still use the camera adapter to connect it to almost any USB DAC, can't you? That's an acceptable situation, IMO.
  8. Would you consider adding a subwoofer? There is something of an online consensus that the Adam monitors have less deep bass than comparable size speakers from other companies, and therefore have a stronger need for a sub. I have the A5X, and I think they're very good, but without a sub I would not find them acceptable. Sent from my iPhone using Computer Audiophile
  9. Does Spotify still have a lot of content with audible watermarking? Sent from my iPhone using Computer Audiophile
  10. Now this is interesting. Just to be clear, are you saying that the MQA library performs the EQ in the Bluesound player? How flexible are the EQ capabilities in the MQA library? I could imagine anywhere from a handful of boost/cut settings to a full three-parameter shelving filter, plus a parametric peaking filter that could be cascaded as many times as needed. If it's anything like the latter, then it sounds to me like you're very close to the point where you could write an MQA player that would perform fairly general room-correction DSP, incorporating the MQA library that you got off the Bluesound player.
  11. Here is an example of what I consider to be a benign form of DRM. I have an ebook that I downloaded as a PDF with a notice at the bottom of every page giving my email and a transaction number, and indicating that it was created for my exclusive use. It is viewable on Adobe and non-Adobe PDF readers alike, but I will assume that Adobe's authentication system is strong enough that I would not be able to strip all identifying information and create another PDF of comparable quality and file size untraceable to me. If I were to distribute the file online, it could get back to the publisher, and they would know that the unauthorized distribution was from me. Thus, this use of digital technology strongly discourages me from distributing the PDF online. If I really wanted to do that, I'd probably create an untraceable email address and financial account to buy these ebooks. How does MQA compare? I'm sure that every valid MQA file can be traced to its creation. It is likely that download or streaming sites have the capability to create uniquely identifiable MQA files for each customer. It may or may not be possible right now to take an MQA file and create a high-res file from it that has equal quality and is not traceable to it. If this were all that MQA were about, I would not be bothered by it. If its capabilities for compression of high-res content were clearly outstanding, I would recognize the value. But it is increasingly clear that MQA forces its end-users to listen to the output of mediocre digital filtering and makes various legitimate uses of an audio download difficult or impossible.
  12. On second thought, I'm not sure that what I just described would work. A hacker could get around it by analyzing a collection of authentic MQA files, calculating the checksums occurring therein, and creating a database of checksums associated to known authentication codes. The unauthorized encoding software would then take an audio stream, modify it (hopefully with minimally audible degradation) until it matches one of the known checksums, and then use the associated code to create an apparently authentic MQA stream from it.
  13. I'm confused by this. According to the earlier post, it appears that you've managed to find a way to replace the audio content in an MQA file and still have it light up the blue-light indicator; according to the later post you haven't. Was the earlier post in error? It seems to me likely that an MQA stream would have something along the lines of a checksum of the audio data, encoded through a public-key encryption (encoding key closely held by MQA, decoding key built in to all client devices). That way, the decoder could use the checksum to verify that the data isn't corrupted (as a condition for turning on the authentication light), but a hacker wouldn't be able to create an unauthorized MQA encoder by reverse-engineering client software. At least, that would definitely be a sensible approach. Have you seen any evidence that the decoder is doing something at all similar to what I've described with the checksum?
  14. I agree, the most likely signal chain is 44.1 -> DSD -> 176.4. It's definitely been put through a 22kHz lowpass, but their are tools that will do that even when running at higher sample rates (e.g. AUI). The only way to know for certain that it has been through a 44.1kHz stage is if you see aliasing around 22 kHz, which I don't see here, so that's inconclusive. An analog source is an interesting idea. Analog tape doesn't drop off that abruptly, but I have downloaded recordings sourced from analog that I thought sounded better when I lowpassed them, reducing the hiss and distortion associated with tape at high frequencies, so maybe a transfer engineer followed that logic and did analog -> DSD (with 22kHz lowpass), followed by the conversion to 176.4. As to the noise from DSD, it's much higher for DSD64 than DSD128, so I would not expect to see a difference between DSD64 -> DSD128 -> 176 compared to DSD64 -> 176.
  15. On such an old recording, perhaps the most likely explanation for what we're seeing is that the the original ADC ran internally at 64x, 1-bit, and output PCM with some observable DS modulation noise. In that case, the original master format could be 24/88 that looks converted from DSD, even though DSD was never recorded. This isn't a possibility that I considered when I assumed that I was looking at a fairly new recording – almost all modern ADCs are going to run at a much higher rate internally.
×
×
  • Create New...