Answers.Body: <p>I think it's essentially the same answer to both questions.</p>
  <p>In general (regarding development of software algorithms), a clearly defined specification and/or standard is required to get the same result from the same input. I wasn't familiar with TFSD but after googling see that it is an acronym for <a href="https://rdrr.io/cran/seewave/man/TFSD.html" rel="nofollow noreferrer">time-frequency second derivative</a>. It looks like this is more of a concept than a clearly defined algorithms, so it seems reasonable that there could be more than one way to estimate this quantity.</p>
  <p>Without a clearly defined and well-standardised specification that can be followed, software developers have some latitude when translating a concept into an algorithm.</p>
  <p>There are a number of factors that can lead to differences in implementation of a concept -- even if all input parameters are the same. These factors might include: the specific details of the algorithm/software implementation, the programming language, low-level data types, and additional libraries that are used.</p>
  <p>If you really need the scikid-maad result, but want to do everything else in R you could look into the R package reticulate (<a href="https://cran.r-project.org/web/packages/reticulate/vignettes/calling_python.html" rel="nofollow noreferrer">https://cran.r-project.org/web/packages/reticulate/vignettes/calling_python.html</a>) to call Python code from within R. Or if it's the seewave results that you require, but you're working in Python, then the rpy2 package (<a href="https://github.com/rpy2/rpy2" rel="nofollow noreferrer">https://github.com/rpy2/rpy2</a>) seems to be the way to achieve that. NB: Though I'm aware of these packages, I've never actually used them myself, so can't comment on how easy they are to use or how well they work.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-15T22:36:53.967Z
Answers.LastActivityDate: 2024-02-15T22:36:53.967Z
Answers.UserDisplayName: Brian Miller
Answers.Body: <p>Thank you Brian for the answer. I will look into these packages.</p>
  <p>@WMXZ input: any wav file, routine used: TFSD from seewave and TFSD from scikit-maad using the same parameters, I expected the same output.</p>
  <p>So far, I think the main difference is in the spectrogram computation that feed the algorithm.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-16T09:00:19.127Z
Answers.Text: bernabeu-a, OK, but this is better added as comment and not as a answer to original question. Also, in order to dive into the code, one would need all the parameters used. Otherwise, it results only to philosophical discussion
Answers.UserDisplayName: WMXZ
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-02-16T08:52:52.157Z
Answers.LastActivityDate: 2024-02-16T08:52:52.157Z
Answers.UserDisplayName: bernabeu-a
Body: <p>I noticed a difference in output when computing the TFSD using the seewave R package and the scikit-maad implementation in python.</p>
  <p>Is there any justification and is it possible to get the same result from the same input?</p>
  <p>Regards,</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-02-15T17:12:25.210Z
Comments.Text: please provide additional information about the differences, routines used, what is the input, what did you expect and what are the outputs.
Comments.UserDisplayName: WMXZ
Tags: <r><python><audio>
Title: Difference TFSD from seewave and scikit-maad
ThreadText: # Difference TFSD from seewave and scikit-maad
  
  (Asked by: username_0 on 2024-02-15)
  
  I noticed a difference in output when computing the TFSD using the seewave R package and the scikit-maad implementation in python.
  
  Is there any justification and is it possible to get the same result from the same input?
  
  Regards,
  
  **Tags:** r, python, audio
  
  > **Comments:**
  > **username_1**: please provide additional information about the differences, routines used, what is the input, what did you expect and what are the outputs.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2024-02-15. Score: 1
  
  I think it's essentially the same answer to both questions.
  
  In general (regarding development of software algorithms), a clearly defined specification and/or standard is required to get the same result from the same input. I wasn't familiar with TFSD but after googling see that it is an acronym for [time-frequency second derivative](https://rdrr.io/cran/seewave/man/TFSD.html). It looks like this is more of a concept than a clearly defined algorithms, so it seems reasonable that there could be more than one way to estimate this quantity.
  
  Without a clearly defined and well-standardised specification that can be followed, software developers have some latitude when translating a concept into an algorithm.
  
  There are a number of factors that can lead to differences in implementation of a concept -- even if all input parameters are the same. These factors might include: the specific details of the algorithm/software implementation, the programming language, low-level data types, and additional libraries that are used.
  
  If you really need the scikid-maad result, but want to do everything else in R you could look into the R package reticulate (<https://cran.r-project.org/web/packages/reticulate/vignettes/calling_python.html>) to call Python code from within R. Or if it's the seewave results that you require, but you're working in Python, then the rpy2 package (<https://github.com/rpy2/rpy2>) seems to be the way to achieve that. NB: Though I'm aware of these packages, I've never actually used them myself, so can't comment on how easy they are to use or how well they work.
  
  
  ---
  
  ### Answer by username_3 on 2024-02-16. Score: 0
  
  Thank you Brian for the answer. I will look into these packages.
  
  @username_1 input: any wav file, routine used: TFSD from seewave and TFSD from scikit-maad using the same parameters, I expected the same output.
  
  So far, I think the main difference is in the spectrogram computation that feed the algorithm.
  
  > **Comments:**
  > **username_1**: username_3, OK, but this is better added as comment and not as a answer to original question. Also, in order to dive into the code, one would need all the parameters used. Otherwise, it results only to philosophical discussion  
  
  ---
  
  