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.

Sign up for GitHub

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

Jump to bottom

Chain xvector #7

Open
wants to merge 2 commits into
base: xvector
Choose a base branch
from
Open

Chain xvector #7

wants to merge 2 commits into from

Conversation

pegahgh
Copy link

@pegahgh pegahgh commented Feb 17, 2016

This pull request contains some design idea for vector-perturb-signal egs.

@danpovey
Copy link
Owner

sorry I am a bit sick and haven't got to this yet... I'll try to check it
soon.

On Tue, Feb 16, 2016 at 7:49 PM, pegahgh notifications@github.com wrote:

This pull request contains some design idea for vector-perturb-signal egs.

You can view, comment on, or merge this pull request online at:

#7
Commit Summary

  • added new binary and codes for universal feature extractor.
  • modified binary nnet3-xvector-perturb-signal-egs.

File Changes

Patch Links:

—
Reply to this email directly or view it on GitHub
#7.

danpovey
danpovey reviewed Feb 18, 2016
View reviewed changes
src/feat/signal-distort.h
"The numebr of samples in input frame as product of frame_length by samp_freq.");
opts->Register("negation", &negation, "If true, the input value is negated randomly.");
opts->Register("noise-egs", &noise_egs, "If supplied, the additive noise is added.");
opts->Register("rand_distort", &rand_distort, "If true, the signal is slightly changes"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use - not _.

@danpovey
Copy link
Owner

I think I said previously that the signal-perturbing code should go in the xvector directory... actually scratch that, because that directory doesn't exist, the pure-xvector stuff goes in the ivector directory, and other stuff that depends directly on nnet3 goes in the nnet3 directory.
Anyway, maybe don't worry about this too much for now.
I think it would be better to have your signal-level xvector work done in a separate branch for now - probably a branch in your own repository - because it's possible that we'll want to commit the speaker-id-based xvector stuff to the trunk before the signal level stuff.

Dan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@pegahgh @danpovey