Screen Shot 2026-03-02 at 4.18.40 PM.png
- 444.29 KB
(2003x1640)
So I've been working on a project to create a singing voice synthesizer I'm basing it on the description in Jordi Bonada's PhD thesis "Voice Processing and Synthesis by Performance Sampling and Spectral Models". After a lot of trouble with getting TWM f0 estimation to work, I've finally gotten to implementing MFPA (Maximally Flat Phase Alignment". And amazingly, it seems to have worked first try. Compare my results: https://i.ibb.co/dsvgv0fd/Screen-Shot-2026-03-02-at-3-54-48-PM.png To the results in the study: https://i.ibb.co/C3fjdWVd/Screen-Shot-2026-03-02-at-3-55-09-PM.png
Screenshot 2026-10-10 at 2.04.16â¯AM.png
- 42.19 KB
(1140x278)
I just checked the number of lines of code for the first time. I was thinking it may be 5,000. Well it turns out I just hit 10,000.I just checked the number of lines of code for the first time. I was thinking it may be 5,000. Well it turns out I just hit 10,000.
>>13186
To find mistakes in your code, for example. Or to explain stuff to you. Like when instead of actually reading the documentation you just ask an LLM.
>>13207 I base my work on resources I have read, along with my own research. Main works cited are: "Voice Processing And Synthesis By Performance Sampling And Spectral Models" by Jordy Bonada "Understanding Digital Signal Processing", Third Edition, by Richard G. Lyons (RIP) "The Science Of The Singing Voice" by Johan Sundberg In addition to these, I have read many dozens of other papers and theses. Also, I have done my own research. Although I am still working on it, and a lot of it has yet to be tested, I think I may have made some improvements in areas. A big reason for how I have been able to achieve this was actually because I was so quick to cast doubt on my own work. Originally, I thought I had come up with a brilliant innovation. One night, from looking at figures, I actually had a little bit of doubt. Instead of just brushing it aside, I spent hours obsessing over minute details in figures. Eventually, I re-read some things and then I came to the conclusion that my algorithm was based on a fundamental misunderstanding of how the voice system works (although it would actually work some types of sound sources; for example a theramin). I think about a week later, I was back with a new idea. Long story short, this was also wrong. I spent a good portion of a day experimenting and seeing it all break down, which on the other hand strengthened my understanding. As I went to bed, feeling a bit devastated. I began thinking about ideal trains of voice pulses. This led me to come up with a rough idea that the harmonics of a series of overlapping pulses are exactly equal to a sampling of the spectrum of a single pulse. This made me feel a lot better. The next day, I wrote down a proof in LaTeX. A few days later, I came up with a third iteration of the solution to this particular problem. A few days later, I came up with a better idea. A few weeks later, and I came up with an even better idea based on the same principle. Since then, it has stayed mostly the same, although with a few minor tweaks. I think it should work now, although it is still not implemented. This is an example of just one of many things I have worked on within this project. >To find mistakes in your code, for example. I've been hearing a lot from people that LLMs can find the sort of bugs people miss for decades. I very recently caved and decided to run an LLM on most of the codebase. I posed not as myself but as an external reviewer. Needless to say, it found some issues. Many were "pedantic", but this was actually kind of what I wanted to find. There were some false detections. On the other hand, there were some real bugs I thought were false detections at first. Anyway, I should note that every issue that was found were basically minor programming mistakes, but no issues with the program design itself or the algorithms used. Anyway, what I did was I compiled a list of all the issues it found and began looking through them. In the process of fixing the issues, I actually found several more issues, which I also fixed. >Or to explain stuff to you. Like when instead of actually reading the documentation you just ask an LLM.down Not really applicable, since the main library does not have any dependencies. The GUI toolkit uses FLTK, but FLTK has pretty good documentation, which I've read a good amount of.
>>13208 Jordi Bonada* I need to sleep
Screenshot 2026-10-10 at 11.59.19â¯PM.png
- 528.19 KB
(1836x1556)
I have implemented an improvement to the laryngograph onset detection procedure. In typical laryngograph signals, like most signals, there is high-frequency noise. However, in addition to this high-frequency noise, there is also an abundance of low-frequency noise, usually much more than the high-frequency noise. This is due shifting of the neck and laryngograph. The standard DSP solution to this problem would be to use a highpass filter. However, the frequency of this noise, and thus the required transition band, are so low that it would render a standard single-stage FIR highpass filter impractical. The complete procedure I have implemented is follows: 1. The signal is lowpass-filtered (to filter out the high-frequency noise). 2. Peaks (which correspond to glottal closure instants) are detected and interpolated using quadratic interpolation. The topographical prominence is also calculated for each peak, and peaks below a minimum prominence are discarded. 3. In between each adjacent pair of peaks, the minimum valley is found (also using quadratic interpolation). 4. An envelope is created using the natural cubic spline algorithm from this set of minimum valleys. 5. This envelope is subtracted from the original signal. 6. The signal is filtered again, replacing the old filtered signal. 7. Peaks are detected again, replacing the old set of peaks. 8. These peaks are grouped into regions using two heuristics: distance between subsequent peaks and change in subsequent distances. 9. Regions with only one peak are discarded. Another approach would be to use two-stage downsampling. Then, it could be further lowpass-filtered to obtain fine-control (the new sample rate is chosen to be efficient, not necessarily precisely what is desired). These values could then be used in the same interpolation procedure; alternatively, they can be upsampled back to the original sampling rate (also using a two-stage process for efficiency reasons) and this signal subtracted from the laryngograph signal. This approach is more correct in theory. On the other hand, this assumes a perfectly periodic signal. In reality, the laryngograph pulses vary. Furthermore, they are most definitely not period around the start and end of voiced regions. This aperiodicity will distort any filtering operation. On the other hand, the valleys in between pulse generally vary much less than the signal overall. Two stage downsampling is also less efficient than the spline approach.
it's bad
