Repository navigation
Feature: initial time for Signal class #195
Description
Activity
So you have two datasets, which differ in sample frequency. That's a problem which I occasionally face as well.
If we would add a reference time to
Signal, then at least you can compare the outputs as you want to do now.However, it still does not allow putting signals with different sample frequencies in the same Signal. Which is a pity. Also, should it be necessary that the different channels in Signal all have the same starting time or not? Pandas would solve both issues, but would introduce others. And I don't see a pandas based Signal appear anytime soon though.
I understand your point, and am slowly getting more convinced :-)
It's a small change, with no impact for users who wouldn't use the feature, but a change which does have some nice benefits.About you question on multi or single t0
I can guess that implementing initial time will need some changes in the following methods depending if multi or single initial time is implemented fot multichannels Signals.
I am a little confused; but maybe I can give you some inputs:
- all np indexing and methods like reshape, flatten could lead to some inconsistent results depending on starting time implementation, but this is maybe an issue in the actual acoustic too; for example:
s = Signal([0,1,2,3,4,5,6,7,8,9],10) s2 = s[[0,2,4,6,8]] print(s.fs == s2.fs)
s2 is of class Signal with same sampling rate as s1. This could be seen as inconsistency.
Whath to do for the attributet0?
Maybe the easier solution is not to allow indexing on signals (or return np arrays)- A multi starting time implementation coul lead to interesting usages (moving windows with time reference) if consistent with reshape.
- othe methods like correlate or pick will need some improvement
I have given a look how
pd.Serieshandle reshape and it return a np array and can't handle multiminesional dataAt least i feel that the simplest solution (single
t0) will lead to less problems.The example you show above is indeed a limitation which we will have to live with as long as a numpy array is used. When pandas is used this would not be an issue, since each sample would have a specific time, and from that you could derive the actual sample frequency.
I agree that in cases like that it should either return an array, or a Signal with the proper sample frequency, #196
Pandas is column based. The idea is that a single signal is represented by a Series, and that multiple signal channels can be represented by a DataFrame.
A multi starting time implementation coul lead to interesting usages (moving windows with time reference) if consistent with reshape.
This is exactly where pandas is good at. Each signal is considered separately within the DataFrame, but you still have a common index.
The t0 attribute
I think I will add the
t0attribute. It will have the same limitation as the sample frequency, i.e., it's the same for all channels.
@felipeacsi do you have any view on this?Thanks for the mention @FRidh .
Hello @e-sr ! Good to read that you are using this package. I have some comments about your changes.
Have you considered to use oversampling to obtain the signals with the same frequency? Do you have any complaint about it? I think is the simplest solution.
Regarding
t0, if Freddy doesn't anything against it I'm ok. IMHO the plot methods would be better as functions inimaging.pyand then imported insignalbut I don't know if there are issues about cython or other things and I'm giving my opinion without understand all the internals.Hi @felipeacsi,
I don't understand correctly what you mean, but If you think oversampling at measurement is no more possible. I didn't do the measurements (next time I will require it). If you think by interpolation i don't think will be easier.
As you point out the plots methods have to be revisted My changes are something quick to get results without understandig the full package structure (I didnt' do a pull request beacuse of that).
It's not necessary to do new measurements. The oversampling should be to do as a post measurement processing to prepare the data. In audio often you have signals with sample frequency 44.1 kHz and 48 kHz. So, if you need to have the same frequency you need to perform oversampling to the first signal (sample frequency 44.1 kHz). Of course, you can downsample the 48 kHz signal too. I'm far from being an expert but I think the downsampling could lead to errors (aliasing and such things) if it's not performed in a good way.
Have you checked scipy.signal.resample? I found this link in the amazing python-audio guide which collects a lot of information around this topic. Specifically, the link is listed under interpolation section. Also, this post is listed and the author do the trick through a script that he shares. Take a look at comments 6 and 7. Maybe is not what you are looking for but you can get the point. It seems there is a better way through scikits.samplerate but the package is abandoned since 2009.
I hope this can help you.
TL;DR: Try scipy.signal.resample
Thanks for the links @felipeacsi
You're right about those plotting methods. It just naturally grew this way. I prefer to have most Signal methods available as functions as well, so it's on the list :-)
Resampling is an option when you absolutely need the same sample rate. I wouldn't advice doing that unless absolutely necessary since it always comes with additional errors.
In this case it's basically just about being able to put two signals with different sample frequencies next to each other, and when making a selection in time, you get the appropriate samples of each signal.
As I mentioned before this is exactly what pandas is great for. However, since a Signal based on pandas won't come anytime soon, I think we can add a
t0attribute. It's not perfect - neither isfs- but it does solve certain issues without really creating any problems.Thanks for the links @felipeacsi
A ton of interesting things to read!You're right about those plotting methods. It just naturally grew this way. I prefer to have most Signal methods available as functions as well, so it's on the list :-)
Sure, no problem. I think it's good to develop a software like this to speed up your work and don't care much about doing the perfect library™ which for me is hard (and with matplotlib, the perfect dream :D).
Resampling is an option when you absolutely need the same sample rate. I wouldn't advice doing that unless absolutely necessary since it always comes with additional errors.
Yes, I'm aware of that especially in downsampling. Please @e-sr take this into account to your case.
As I mentioned before this is exactly what pandas is great for. However, since a Signal based on pandas won't come anytime soon, I think we can add a
t0attribute. It's not perfect - neither isfs- but it does solve certain issues without really creating any problems.Sorry, I forgot to mention about pandas in other posts. I agree that is an excellent option to avoid things like this and I'm aware the complexity this could introduce to adapt the existing code.
@e-sr suggest adding an initial time
t0to Signal.See https://github.com/e-sr/python-acoustics/commit/1c13adb99a587de4d3d8adb630c978f649285737