Jump to content

happybob

  • Content Count

    63
  • Joined

  • Last visited

About happybob

  • Rank
    Newbie

Recent Profile Visitors

2303 profile views
  1. Thanks for the perspective! I'm wondering, do you then do 2 sets of PGGB upsamples, one with 16FS/32bits and another 16FS/24bits? Also wondering what BNC cables you use? I can have an entirely different feed to Dave directly for PGGB tracks, but since I've found the opticalRendu to make a big improvement in SQ (I'm not yet at the point of having a Taiko although I'd like to get there, am currently using Roon via a SonicTransporter i9 as source), that means I'd need yet another opticalRendu/LPS to feed Dave or an SRC-DX directly and then another 2 BNC cables. This makes for a lot more $ and als
  2. I've been testing with v1.2.07 several "challenging" albums (i.e. 44K/16 classical albums with long tracks) with my M1 MacBook Pro (16GB RAM, 2TB SSD with 1TB free) and I can reliably do 256MTap (1 worker) conversions (16FS, 24 bit) - I'm using a Chord Dave Dac (with SJ DC4 LPS), currently through a Chord MScaler (since I also use the same setup for streaming audio and PGGB can't process streaming tracks, an opticalRendu feeds the MScaler which then feeds the Dave via 2 Blackcat Tron BNCs). So even though the MScaler also upsamples everything to 7xxK, I find the PGGB tracks to soun
  3. I love the "to OOM it may concern"! Ha! I'm doing some more testing (various numbers of taps and "workers") on my M1 Mac and sharing files with ZB for evaluation. No clear resolution yet although part of the problem may be the M1 Mac itself vs an older intel Mac. More news to come after further testing by me and further eval by ZB. And I'll second @kennyb123 comments about istat menus!
  4. Thanks ZB, I've been meaning to reply directly to you via email. I see the message: Estimated memory per worker: 2GB of 16GB RAM Sugested max workers: 8 I also frequently see the message "Error in function PGGB.Continue() at line 906." Another thing - sometimes the process does restart but other times it doesn't restart ever. And sometimes the whole app crashes. I've attached a failed upsampling attempt log... PGGB_album_debug.log So it does appear that the Mac is not able to do this particular track with anything more than 32Mtaps. Ma
  5. Thanks for the perspectives on the Mac issues! I'm thinking maybe the M1 Mac is the problem too. My current M1 MacBookPro has a single 2TB SSD that's still got 1TB of free space available. I have VMWare fusion but haven't run it yet on this M1 Mac. Maybe I do that, although I'd sure prefer just staying with the Mac directly and not having to run a VM. I do plan to upgrade to the "likely coming soon" M2 (or maybe M1x label) MacBook Pro that's rumored to have up to 64GB of RAM. But it's still a rumor although seems likely, but maybe not out for a few months. I'm going to do some mo
  6. I'm a new user of PGGB (have been testing and just bought my license). I love the resulting sound improvements! (Dave DAC with Sean Jacobs DC4, doing 16FS, 24 bits or 32bits being evaluated). But I am currently running it on a M1 MacBook Pro (>1TB of free SSD space and 16GB of RAM) so it's an underpowered machine for PGGB although I am wondering if you have any thoughts about: 1. Best way to optimize this Mac (regardless of speed of processing PGGB files) for higher taps (currently on classical pieces I'm limited to 32Mtaps unfortunately before the dreaded "out of application me
  7. Yes, redoing upsampling (with more taps) is certainly possible, but I have ~3000 CDs (ripped) plus some other downloads that I want to process so it'd be quite a bit to redo. I'm likely to just target the low hanging fruit soon (albums with short tracks or even some with longer tracks that I'm fine with redoing later) and then do the rest later. Of course it's not like I'm listening to all 3000 albums now in any case, although I would want to save the "big" conversion until I can do it more optimally. p.s. My apologies for this being a duplicate post - I had an earlier post that in
  8. Thanks for this info. I listen to a very wide variety of music, much is shorter tracks but I do listen to quite a bit of classical and so that'd be an issue. I'd like to avoid doing multiple rounds of upsampling my library - so what I might do is to only process the albums with shorter tracks and then wait for those longer ones till I get my new system (will likely be the coming MBPro with **rumored** 64GB of RAM and M2 chip). I don't really want to have yet another computer just for processing PGGB files at least not at this point.
  9. I'm wondering how much difference in sound quality (subjective I know) to 16FS with a Dave DAC is there between 256M taps and maximum number of taps (if I had a machine with 128GB RAM) for 44K/16 originals? I have a MBPro with 16GB of Ram, although will be upgrading this year to the coming new M2 MBPro with 64GB RAM, but most of what I'd upsample is 44K.
  10. This statement that there are few albums that stay in DSD the entire path is so true and so hard for most DSD enthusiasts to acknowledge. Now some folks (who use a DAC that sounds best with DSD and/or that doesn't benefit from PGGB) might still prefer the sound of a DSD final version but this might say more about their specific DAC than it does about the underlying information truly available in the recording.
  11. I haven’t seen any indications of SQ improvements but the Roon folks do have a history of not always telegraphing various future version changes. They are certainly aware of the SQ issue, hopefully they do implement something (like the “one zone only” HQ mode). Another reason I’m hopeful is that Roon has indicated 2.0 will be a major upgrade in many respects.
  12. I do hold out some hope that the coming major upgrade to v2.0 might address some of these SQ issues. Maybe not high probability, but still a possibility.
  13. Thanks for clarifying! Was there a reason given as to why a PLL is used in the May? I'd rather not slog through 40 pages of post responses to find it if it's even stated. Thanks!
  14. It's my understanding that usually an asynchronous USB transfer will not use a PLL, rather it receives the input with the transmitted data rate / clock and then sends it onward (into the DAC in this case) with a completely separate clock that's in the DAC. Am I missing something? Why does the May have a PLL at all if it can completely isolate the input and output clocks for the USB stage?
  15. Thanks much for this great post and info! I'm wondering if your system is primarily (or exclusively) a headphone based system or if your great front end also feeds a speaker system(s)? I'm primarily a headphone user for "really focused listening" although I also have pretty good speaker-based systems I want to focus on improving soon, so many options to move forward with! I'll be moving forward to test PGGB as we've communicated in PMs, but haven't done that just yet. I've really appreciated your (and the original beta folks') perspectives on that SW. Thanks again!
×
×
  • Create New...