Posted on

D1 Team Status Report 2/15

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

Our biggest risks at the moment are coming from our signal processing for scoring and from our ability to do vocal removal with low latency. Scoring is risky because as we have recently moved away from pitch detection, we are now developing new ideas for metrics and if we are not able to select one and start testing it as soon as possible, we leave a risk of missing out on a major component of our gamification. For our vocal removal, we have confirmed that it is possible with low latency via software, but we still need this to become a hardware system ideally. Both risks are being managed by quick decision making, as we are finalizing design choices right now and are hoping to be able to quickly get to a testing phase and prototype these pieces as soon as possible. As far as contingency, for our scoring, we have a range of options including some extremely easy (but unideal) work arounds. For the vocal removal, there is always the option to use an AI model to do the work which is proven to be possible.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

The primary change is switching from a bandpass / bandstop filter to the subtraction method taking advantage of stereo output. There is not much as far as surface level cost, but this does limit our potential music library to only songs that exist in stereo format. It will simply require a small check with the Spotify API to verify before allowing the user to confirm.

 

Additional Questions:

Part A (Written by Kiera): JustPerform is designed to promote the psychological well being of our users by creating a simple and affordable at home karaoke experience. Self expression through singing and dancing can be an effective way of alleviating stress and improving your mental health. Our product makes this possible for those who may not be able to afford to go to a karaoke venue.
Part B (Written by Aleks): JustPerform promotes social interactions by providing a fun group experience for at-home events. Music and dance are universal cultural expressions, and by allowing users to convert their personal music libraries into karaoke tracks, JustPerform allows for greater personalization and culture, accommodating different musical tastes and traditions. Additionally, the incorporation of dancing produces physical activity, promoting health and well-being.
Part C (Written by Hugo):
From an economic perspective, JustPerform presents an affordable alternative to traditional karaoke systems, combining all of the facets of the karaoke experience into one product. Additionally, by allowing the user to use their own library, there is no limitation of traditional karaoke machines which are limited by the preloaded library they come with. Additionally, its multi-functionality appeals to a broad market, including households, party venues, etc. , increasing demand and potential revenue streams
Posted on

Hugo’s Status Report 2/15

Continuing on where I left off last week, this week I spent my time looking into the specific methods for implementing the system. Because I am our primary audio processing lead, my work revolved around fleshing out not only systems for vocal removal, but also how generally getting the full outline for how our data is being passed around and what kind of processing we need to do. First, after our proposal presentation, we had a slight change of path with regards to how we want to do scoring for our game. Originally, we had intended to work with pitch detection but now wanted to find something that more accurately captured the karaoke experience for the average user. We came up with a series of new metrics and strategies, and are continuing to analyze and pick a specific plan. Then, I took time to investigate the vocal removal aspect. Because this is currently such a fundamental part of the project it is imperative that this works as expected. I used matlab to do some tests by passing through audio files to see the effects of our original bandpass and bandstop filtering idea. In the end, this was not effective. Although the bandpass could kind of get a weak signal that almost isolated the vocal (often leaving in percussion), the bandstop filter was next to useless at removing the vocals from the backing track. So, I moved on to testing methods that take advantage of audio in stereo format to cancel out the vocals by subtracting the left and right channels. In the end, this did provide favorable results while still allowing us to work with a hardware system as we had originally hoped. Then I took time to read into the actual wiring and built up a design for splitting the two audio channels, passing through our subtractor, adding in the microphone input, and outputting to a speaker. I also took some time to look at possible speaker options and assessed whether this was a part that we wanted to allocate substantial amount of the budget to, as it is crucial that the sound quality is high for the product to reach our user requirements.

Posted on

Aleks’ Status Report 2/15

This week, I focused on working through our design requirements with our group. I participated in multiple group sessions to brainstorm the best solutions and both ask for and provide feedback on our individual project research areas. I continued my research into the Spotify API to ensure it met our updated requirements. I also did research into discovering the best strategy to retrieve lyrics for our application. I spent time researching and evaluating multiple APIs, web resources, and tools for accuracy and availability. We also got feedback that our GANTT chart needed improvement. I created a true GANTT chart and updated the tasks and timeline to be more fully fleshed out and aligned with our new design decisions. I also spent substantial time working on our presentation slides and going through gradual iteration and revision with my group. Next week, I hope to spend a bit of time actually building with our resources, then I will focus on our design report, taking into account any feedback from our presentation.

Posted on

Kiera’s Status Report for 2/15

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week.

This week I continued to work through and finalize the design of the microphone and accelerometer system. I spent time researching tradeoffs of different microcontrollers based on our design goals of having it fit on the microphone, having easy communication with the software, not adding too much latency to the system, and not being too expensive. Additionally, I looked into the option of using camera vision instead of an accelerometer to track the user’s motion but decided that the accelerometer system fits better with our design goals and CV will be a contingency plan. 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is on schedule. 

What deliverables do you hope to complete in the next week?

By next week I hope to have tested parts of the accelerometer system using spare components and to have further fleshed out the design in the report.

Posted on

Team Status Report for 2/8

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk we are currently faced with is making the wrong choices in our early design stages. To manage this risk, we have each spent the week researching the tradeoffs of the design choices we each need to make in our portions of the project. For the larger technical challenges of our project we plan to test our proposed solutions to them early in case they do not work out the way we expected. Our primary contingency plan consists of having planned out alternatives ahead of time in the case of a fall-through with our current design.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

The main change made to our existing design was the connections between all of the components. Originally, we planned to have the microphone send motion and audio data to the computer while also sending the audio data straight to the speaker. We decided this would be an awkward wiring system for the user and instead opted to send everything through the computer, especially as our original design included some filtering of the microphone signal which we deemed unnecessary after research. We also previously planned on using a hardware filter to separate the vocal from the backing track in the speaker but decided this would be more achievable using software.

Posted on

Aleks’ Status Report 2/8

This weekend, I prepared to present our project proposal presentation. During the week, I looked more deeply into Spotify API to analyze exact functionalities that would be useful and make sure all of our use cases for their data followed their usage guidelines. I found some interesting audio analysis features that are notated as deprecated, but I want to do more research into. I also set up our GitHub repository and initialized the Django Webapp so I can do some work through Spotify’s tutorials next week to make sure we can load the music appropriately. I also did some review and practice coding web applications to brush up on my skills. Additionally, I met with my team to brainstorm through some of our system design decisions based off of presentation feedback. Next week, I plan to dig into our design decisions next week to determine our best design plans. I will ensure Spotify works for our use cases and look into best methods for procuring our lyrics, especially using a potential fix that a student in our section (Maya Doshi) told us could be useful.

Posted on

Kiera’s Status Report for 2/8

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week.

This week I researched the logistics surrounding the motion tracking portion of the project to prepare for our design presentation. The main questions I looked into answering were “What board would be best fit for connecting the accelerometer to?” and “How can we use the accelerometer data to detect change in direction?”. Considering our design goal of keeping the product lightweight and portable, and since we don’t require a large amount of processing power on the hardware end (a majority of our computation will occur in the software), I found that a microcontroller (likely an arduino) would be the best choice for our design. With this taken into consideration I searched for existing arduino projects that used an accelerometer in a way similar to how we intend to and found that the MPU6050 sensor is a good fit for our needs. The MPU6050 gives acceleration (x, y, z) and angular velocity data (x, y, z). Changes in sign of any of the components could be used to indicate a change of direction of the user but I plan to continue to look into other algorithms to give more accurate results.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is on schedule, as I have done enough research to make the design choices in my portion of the project that are necessary for us to move forward. 

What deliverables do you hope to complete in the next week?

In the next week I hope to have developed a diagram of the motion-tracking/microphone system, including specific components, the connections between them, and the system’s connection to the computer. Additionally, I plan to do more research on algorithms that use both the acceleration and angular velocity metrics to detect change of direction, or potentially other indicators that the user is moving to a beat. 

Posted on

Hugo Weekly Journal 2/8/25

The beginning of the week I was tasked with fleshing out our testing plans. Our original abstract had the fundamental ideas but was missing detailed explanations of how we intended to accomplish this and so I created more thorough details on our plans. After our design presentation, I moved on to researching methods for how we could extract and analyze the singer’s pitch. I started with design work, making final decisions about how we would connect our microphone to both our computer and our speaker and decided that it would route directly to the computer as opposed to our original plan of through the speaker. Then I looked into python libraries for pitch detection, first looking at librosa which is a commonly used one by some of our classmates, but decided to start with aubio. Aubio’s main selling point for us is a method that can do pitch detection from streaming data which is a stretch goal for our project.

My progress is mostly on schedule, as my first tasks are all related to microphone audio processing and so having found the necessary libraries and planning out the design was a very good start. However, I want to start testing the software as soon as possible and so next week I will ensure that on top of my planned research I create a proof of concept for this process.

Posted on

Introduction and Project Summary

Despite its popularity, karaoke at home is still a tedious and fragmented process. Our project is a seamless karoake experience which removes audio from user’s personal Spotify library and provides feedback for improvement via audio and motion processing to analyze pitch and tempo.