Skip to content
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

Record silence at the beginning and end of a recording voice client #1980

Closed
denisnumb opened this issue Mar 21, 2023 · 10 comments · Fixed by #1984
Closed

Record silence at the beginning and end of a recording voice client #1980

denisnumb opened this issue Mar 21, 2023 · 10 comments · Fixed by #1984
Labels
feature request New feature request

Comments

@denisnumb
Copy link

Summary

Parameter responsible for whether the VoiceClient.start_recording method will record silence at the beginning and end of the recording

What is the feature request for?

The core library

The Problem

Used this example to record audio from a voice channel. Everything works, in the output I get a separate audio track for each speaking user.

Next, I want to overlay the audio files on top of each other and glue the conversation in the channel into one file, but as a result, all the voices in the file sound simultaneously, although in fact the users speak in turn.

This is because VoiceClient.start_recording() does not record silence at the beginning and end of the user's audio recording.

Thus, if three people say something in turn, then as a result the recordings of their speech will have different lengths and because of this they are mixed into one heap.

The Ideal Solution

I would like the start_recording method to have a bool parameter, which is responsible for the need to record silence not only between the replicas of users, but also at the beginning and end of the recording.

The Current Solution

At the moment, I do not have a good solution to this problem, because. I have to change the methods of the library anyway.

Additional Context

No response

@denisnumb denisnumb added the feature request New feature request label Mar 21, 2023
@OmLanke
Copy link
Contributor

OmLanke commented Mar 21, 2023

This is exactly what I am working on since yesterday haha. I have somehow managed to add silence at the start but it still has some weird bugs which I'm trying to overcome. Feel free to discuss with me regarding this over on the discord server (My username- Om#6974)

@OmLanke
Copy link
Contributor

OmLanke commented Mar 25, 2023

In case you were wondering, I used this code to merge audio

@denisnumb
Copy link
Author

Great! When can I update the library to start using this solution?

@OmLanke
Copy link
Contributor

OmLanke commented Mar 26, 2023

Can't confirm that for you. Although it will be nice if you or someone can test it and report any bugs. You will need to clone this repo and branch to test it https://github.com/Om1609/pycord/tree/voice-recording

@denisnumb
Copy link
Author

I tried to test the entry for multiple users. But it doesn't work the way it should :(

When recording a conversation between two users, the sound of the first one is recorded as needed, and the sound of the second appears only after 2-10 minutes, and until that moment there is complete silence on the recording, despite the fact that the silence time of the second user is actually 5-10 seconds

@OmLanke
Copy link
Contributor

OmLanke commented Mar 29, 2023

I had a very similar finding too. There is excessive amount of silence when recording some users. But I feel it is a bug with certain discord clients, especially web clients. Occasionally, the timestamp on the packet sent by discord is inconsistent. There are very large gaps for very small actual speaking pauses. I have confirmed this testing multiple times, and all have the same result.

This got resolved when i retried my tests from a different device (discord desktop app and my mobile instead of discord web). The only fix to this which i can think of is, to record audio based on packet receiving time and not rely on timestamp sent by discord at all.

But that solution results in degraded quality. And the library should not make fixes and workarounds for bugs by discord

@Lulalaby
Copy link
Member

Yeah the timestamps are mostly shit and incorrect. Rely on receive time.

@denisnumb
Copy link
Author

By the way, yes, problems with the wrong recording time were really observed only for a user with the Web version of the discord. What will be the further development of events on this topic? Will you try to come up with another solution?

@Lulalaby
Copy link
Member

Lulalaby commented Mar 29, 2023

The whole voice receiving is an weird topic.
We don't have any docs ourself, so don't expect too much

@denisnumb
Copy link
Author

Is there any news on this topic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants