Triode wrote: 
> This has changed slightly - can you see if you like/dislike the new
> algorithm which is intended to also allow synchronous downsample of dsd
> converted to pcm


Code:
--------------------
    
  [16:08:06.180649] codec_open:211 codec open: 'd'
  [16:08:06.180678] stream_file:316 opening local file: 
/storage/music/lossless/DSD/Michael_Jackson/Thriller/07 Human Nature.dff
  [16:08:07.240140] _read_header:191 id: FRM8 len: 172976188 consume: 16
  [16:08:07.240237] _read_header:134 DSDIFF version: 1.5.0.0
  [16:08:07.240258] _read_header:191 id: FVER len: 4 consume: 16
  [16:08:07.240276] _read_header:191 id: PROP len: 370 consume: 16
  [16:08:07.240292] _read_header:138 sample rate: 2822400
  [16:08:07.240306] _read_header:191 id: FS   len: 4 consume: 16
  [16:08:07.240322] _read_header:142 channels: 2
  [16:08:07.240336] _read_header:191 id: CHNL len: 10 consume: 22
  [16:08:07.240364] _read_header:191 id: CMPR len: 20 consume: 32
  [16:08:07.240381] _read_header:191 id: ABSS len: 8 consume: 20
  [16:08:07.240396] _read_header:191 id: LSCO len: 2 consume: 14
  [16:08:07.240411] _read_header:191 id: ID3  len: 250 consume: 262
  [16:08:07.240427] _read_header:145 found dsd len: 172975488
  [16:08:07.240442] dsd_decode:521 setting track_start
  [16:08:07.240456] dsd_decode:537 DSD to PCM output
  [16:08:07.240472] resample_newstream:172 resampling from 352800 -> 176400
  [16:08:07.240489] resample_newstream:193 resampling with 
soxr_quality_spec_t[precision: 20.0, passband_end: 0.913628, stopband_begin: 
1.000000, phase_response: 50.0, flags: 0x00], soxr_io_spec_t[scale: 0.89]
  [16:08:07.241080] process_newstream:123 processing: active
  [16:08:26.094402] _output_frames:122 track start sample rate: 176400 
replay_gain: 0
  
--------------------


Confirmed... Yesterday, DSD -> 352k8 ->async-> 192k. Latest,  DSD ->
352k8 ->sync-> 176k4. Yes, we need to keep the sync behaviour! (Bring on
the ridicule, but I'm pretty sure I could pick this out in a blind
listening test. I still don't know whether this is sox specific, but
right since the early days of lms-upsample, using the sox exe on the
back-end, we have known that the results are much more pleasing sync
than async. We'll certainly, where I'm running into a DAC where no
additional over/upsample or DF is taking place after processing with
sox.) 

Need to think about how this is going to be implemented, but on the
back-end with dsdplay calling sox exe, I'm adding a brickwall "sinc 40k"
to the options to cut the ultrasonic crap above 40k. Last time I looked
at the frequency plots there was quite some crap at around 70k after the
DSD -> PCM conversion. Something I have on my list to come back to.
Don't have time right now, (as per usual).


------------------------------------------------------------------------
JackOfAll's Profile: http://forums.slimdevices.com/member.php?userid=3069
View this thread: http://forums.slimdevices.com/showthread.php?t=99395

_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix

Reply via email to