<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 2:51 AM Linux ROUEN Normandie <<a href="mailto:linux.rouen@free.fr">linux.rouen@free.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    Thanks for your clear explanation and the nice recall of our funny
    early-life! I still have my 33 LP & 45 rpm discs collection but
    I have lost my player. ;-)<br></div></blockquote><div><br></div><div>You can still buy those, they seem to be popular these days again, and many come with a built-in USB audio interface. :)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    
    Well, so I was too demanding regarding the capabilities of such
    Audio objects.<br></div></blockquote><div><br></div><div>VLC has it easier, because it just does linear playback, and in such a case you can, e.g., use libsamplerate to convert the sample rate on the fly. In real time audio programs like Pd, you'd generally want to avoid such costly operations. With soundfiler+tabread4~, you can compensate for the SR discrepancy by adjusting the playback speed, but oggread~ has no provisions for that (probably because it's playing back the file directly from disk, which makes adjusting playback speed much more complicated).<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>So, I do need to spend some time to find out how I can easily
    implement such mechanism within my Purr Data projects by e.g.
    reading the relevant part of the Audio file header and then decide
    what to do either with/around the given Audio player object and/or
    Purr Data settings. I'm continuing to learn each day.<br></div></blockquote><div><br></div><div>You could use the Vorbis oggdec and oggenc utilities to re-encode your ogg files off-line in the sample rates that you need. Generally having 44.1 and 48 kHz versions of each file should be good enough, although some audiophiles will claim that 192 kHz "sounds much better" -- which is a bit like dowsing, never seems to work in double blind experiments. ;-)</div><div><br></div>Albert<br><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    
    What a wonderful community!<br>
    <br>
    Best, Joseph<br>
    <div>- - - - - - - - - -<br>
    </div>
    <div><br>
      Le 15/10/2020 à 01:14, Albert Graef a écrit :<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Hi Joseph,</div>
        <div><br>
        </div>
        <div>Well, if you read something into a Pd array at sample rate
          SR1, and then play that sample data back later (through Jack
          or otherwise) at sample rate SR2, then it will play back with
          a speedup/slowdown factor of SR2/SR1, and pitch will shift by
          the same factor. The audio interface doesn't care where those
          numbers come from. It will happily play 48000 samples of your
          44.1kHz-sampled data in 1 sec, which will speed it up by a
          factor of 48000/44100 = 108.8% and make it sound about 1.5
          semitones higher.</div>
        <div><br>
        </div>
        <div>At least that's what happens if the object decoding the ogg
          file doesn't convert to the target sample rate on the fly. I'm
          not sure whether oggread~ does this.<br>
        </div>
        <div><br>
        </div>
        <div>Joseph, I'm sure you also still remember those glorious
          days when we enjoyed playing back those black "LP" discs at 45
          rpm. It's the same effect, only in digital. ;-)</div>
        <div><br>
        </div>
        <div>HTH,</div>
        <div>Albert</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Oct 14, 2020 at 10:48
          PM Linux ROUEN Normandie <<a href="mailto:linux.rouen@free.fr" target="_blank">linux.rouen@free.fr</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello
          to the Audio specialists,<br>
          <br>
          I'm struggling since a while with an annoying Audio issue
          under Purr <br>
          Data using e.g. [oggwrite~] / [oggread~] with their default
          settings.<br>
          <br>
          Under GNU/Linux for Audio I'm using JACK2 with QJackCtl or
          Ubuntu Studio <br>
          Control and JACK back-end = ALSA.<br>
          I record from an Audio source (synth, micro, line) with
          [oggwrite~] and <br>
          then play it back with [oggread~].<br>
          <br>
          As long as I'm using everywhere (Pd, Jack) the same Sample
          Rate, either <br>
          44100 or 48000, it's all fine - no issue at all.<br>
          But if the Play SR changes (voluntary or not in Pd & Jack)
          vs the Record <br>
          SR, then when playing my Audio song back is running either
          faster or slower!<br>
          <br>
          I thought that the Audio SR had nothing to do with the
          playback speed <br>
          but only, among other things, with the sound quality.<br>
          <br>
          What is wrong in my thinking? Any ideas?<br>
          <br>
          Thank you. Best,<br>
          Joseph Gastelais<br>
          <br>
          _______________________________________________<br>
          L2Ork-dev mailing list<br>
          <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
          <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote>
      </div>
      <br clear="all">
      <br>
      -- <br>
      <div dir="ltr">
        <div dir="ltr">
          <div>
            <div dir="ltr">
              <div>
                <div dir="ltr">Dr. Albert Gr"af<br>
                  Computer Music Research Group, JGU Mainz, Germany<br>
                  Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>,
                  web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
L2Ork-dev mailing list
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div></div>