-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Couple comments on reading #2
Comments
Regarding subests of channels - it's already supported, note the
That's just for the
Alright, let me elaborate on that. Python 3.7 introduced
and it automatically creates default
It also provides a method Also, I find the |
The users of this library are forced to use Python 3.7. If some of them do not have |
Mm. My feeling is the python3.7 thing may be OK... this is a rather forward-looking project, and my feeling is enough people have python3.7 (or could install it in user-space). |
The users can also install Anaconda/Miniconda without sudo permissions and
use any python version they want.
czw., 7 maj 2020, 23:16 użytkownik Daniel Povey <notifications@github.com>
napisał:
… Mm. My feeling is the python3.7 thing may be OK... this is a rather
forward-looking project, and my feeling is enough people have python3.7 (or
could install it in user-space).
If it's a problem later we can always change the code, but for now I don't
want to slow this project down by worrying too much about such thigns.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#2 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADZRKQCXOVNX7E2FT2E6L5LRQN2PZANCNFSM4MRDBQ5A>
.
|
plus python 3.7 was released mid 2018...
IMO it's ok
y.
…On Fri, May 8, 2020 at 8:25 AM Piotr Żelasko ***@***.***> wrote:
The users can also install Anaconda/Miniconda without sudo permissions and
use any python version they want.
czw., 7 maj 2020, 23:16 użytkownik Daniel Povey ***@***.***>
napisał:
> Mm. My feeling is the python3.7 thing may be OK... this is a rather
> forward-looking project, and my feeling is enough people have python3.7
(or
> could install it in user-space).
> If it's a problem later we can always change the code, but for now I
don't
> want to slow this project down by worrying too much about such thigns.
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
> <#2 (comment)>, or
> unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ADZRKQCXOVNX7E2FT2E6L5LRQN2PZANCNFSM4MRDBQ5A
>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACUKYX23ZHEYPS7ZYCABFXTRQP22TANCNFSM4MRDBQ5A>
.
|
Add kaldi style text normalization
https://github.com/pzelasko/lhotse/blob/7555df605def57836c9454ae44aac95c504d86b0/lhotse/audio.py#L21
There should possibly be at least a TODO here to support getting a subset of channels. I'm thinking of scenarios like Switchboard. Since I think typical storage formats store the different channels interleaved, it may be just as efficient to read all of them and then select the needed ones. But there are scenarios where different channels are stored separately (AMI). We have to figure out at what level to do this.
Regarding the raw-PCM thing: I think if there is any common/universal format it would probably be wav, not raw pcm, as raw pcm is too easy to get wrong (no error if wrong format). I didn't really understand the AudioSource code well as your Python style is very modern... e.g. no init function.
The text was updated successfully, but these errors were encountered: