Test the model various noisy datasets to better analyse the efficiency of the algorithm to interpret the noisy data.

Outdated requirements

Produce prototype for RESTful API framework for python evaulation scripts to run within.

Here's a quick list of the papers that I've been reading on the different approaches.

Papers

• Deep learning methods in speaker recognition: a review

• Study of the Effect of I-vector Modeling on Short and Mismatch UtteranceDuration for Speaker Verification

• Deep Speaker: an End-to-End Neural Speaker Embedding System

  • Deep Speaker from Baidu Research - Pytorch Implementation
  • Deep Speaker: An End-to-End Neural Speaker Embedding System - Keras + Tensorflow

Findings

It seems like the Deep Speaker approach looks like it could be a great starting point as "Deep learning methods in speaker recognition: a review" point towards a DNN + i-vector being the most effective, while the Deep Speaker project looks to improve on this.

The project should have a specific LICENSE in order to define build configurations and publish it on PyPI.

Brief

As speaker verification matures, the direction of its finial implementation needs to be considered. This would allow for the project to be a continually evolving extension of Doubtfire. This direction will serve as an effective way to guide next steps on how the project will proceed.

Proposed Technical Stack

• Entire development and production environment, and their dependancies are housed within Docker using Docker Compose.
• Django serves as the web framework for the project. This suits the project due to Python being the language used for the current project.
• Gunicorn serving as the WSGI.
• Celery for task queuing.
• Redis for message brokering with the tasks.
• PostgreSQL for the database.
• Nginx for the web server.

Commentary

This technical stack is based on personal preference, so it would be great to get some feedback. By doing it this way we will achieve the following:

• Removing the need to write SQL Queries. Automatically manage database migrations as the project evolves. Develop models in an easy to read format.

Screenshot of a Django model

• Unified development environment. Setup production or dev environment by setting a few environment variables and running docker-compose -f docker-compose.yml up -d --build
• Make use of established Django frameworks such as the Django Rest Framework.
• Easily develop tests.
• Already has a backend admin panel, incase you needed to easily view / edit data in the DB.

Screenshot of a Django Admin Panel

The direction the RESTFul implementation of this project would take heavily depends on the project's final intentions. For example, if this project were to evolve in a larger contract cheating prevention platform, then building a proper web service might be a good direction to take the project.

It would probably take 2-3 hours to get this all setup and working properly, with some basic documentation.

Looking forward to hearing your thoughts.

• Here, are the pre-trained models we are using: https://drive.google.com/drive/folders/18h2bmsAWrqoUMsh_FQHDDxp7ioGpcNBa. I found that the ResCNN_triplet_training_checkpoint_265.h5 model we have is better than the ResCNN_softmax_pre_training_checkpoint_102.h5 model. If we can train our own model using what was built in https://github.com/philipperemy/deep-speaker, we could potentially get a better model, especially if we get to use more data to train the model.
• This newer research paper called GENERALIZED END-TO-END LOSS FOR SPEAKER VERIFICATION (https://arxiv.org/pdf/1710.10467.pdf) introduces a loss function that makes training our Deep Speaker more efficient and faster. It reduces training time by 60%! This newer paper references the Deep Speaker: an End-to-End Neural Speaker Embedding System (https://arxiv.org/pdf/1705.02304.pdf) research paper our model is based on.
• This project (https://github.com/resemble-ai/Resemblyzer) (https://pythonawesome.com/a-python-package-to-analyze-and-compare-voices-with-deep-learning/) has some cool features we should add to our projects like Fake speech detection and Speaker diarization, but more importantly, it has a voice encoder which is based on the paper GENERALIZED END-TO-END LOSS FOR SPEAKER VERIFICATION I mentioned. This project (https://github.com/HarryVolek/PyTorch_Speaker_Verification) has the implementation of the loss function mentioned before that we can use to train our model.
• In the past for model evaluation validation we have used the VCSK corpus as input but could be used for any model training.

Add simple unit tests for SQL methods as to make sure database is working as expected.

Utilize setuputils for packaged the current project in order to be able to easily install the package to a virtual environment with python setup.py install similar to make for C/++.

Use the following guide to facilitate the packaging:

Building and Distributing Packages with SetupTools

The installation of README.md should be changed to reflect the new installation method.

Include the following:

• Black python autoformatting
  • line length: 90
• Semantic commits for GitHub
• Don't delete stale or merged branches (for assessment reasons)
• Use pytest fixtures and methods for writing tests.
• Run tests before commiting, dont rely on the pipeline
• DRY code

Refactor out denoise.py and encapsulate the function into either existing dependencies like librosa and or wave instead of relying on the custom function. This should be extended to be utilized before the deep-speaker sub-module is called in the enroll and validate workflows are called.

Some sort of test to gauge the effectiveness of this denoise process will be needed in order to justify its runtime costs in this project.

Improve the documentation for the project with the following sections:

• Note module usage
• Environment installation instructions
• project license

The current setup.cfg uses an outdated template format which prevents retrieval of the package using pip. Update using the latest template from setups laid out in (https://packaging.python.org/tutorials/packaging-projects/).

Tasks:

• Update template to new template
• Update version number
• Update contact details

Test requirements:

• Can successfully upload a new package
• Can install that same package uploaded in the previous step

Add tags to end of last trimester as some version which will be built upon this trimester for historical records. This will establish the point where our teams contribution starts from last year.

Use the logging library to setup a logging mechanism to show the process of functions being run.

• Logging documentation
• Gist of logging script

Add integration testing to the enroll_new_user and validate_user function for all required and optional arguments in order to reach full testing coverage in the projects entry points.

Use pytest-cov to generate coverage reports on the code coverage.

Create a coverage badge in the README.md that links to the coverage of tests run in the CI.

• Create a mechanism in the existing python-ci.yml file that takes the coverage value from passing tests.
• Create a coverage badge that displays the coverage value in README.md.

See actions coverage mechanism

Create a markdown file documenting the guidelines for contributing to the project.

• Principles
  • Dry vs Wet
• Pull Requests
• Testing, CI (GitHub Actions)
• Auto-formatting
• Environment