\n
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F12109879%2F439035b8a8fe7eade0060be5faa21ad8%2Fphoto_2025-05-19_14-01-55.jpg?generation=1747652608679091&alt=media\")
After many attempts, I still haven't found a combination of parameters that significantly improves the LB — it consistently hovers around 0.79x.😱😱😱
", "messages": [ { "id": "3203712", "postDate": "05/17/2025 07:59:57", "content": "After many attempts, I still haven't found a combination of parameters that significantly improves the LB — it consistently hovers around 0.79x.😱😱😱
", "rawMarkdown": "After many attempts, I still haven't found a combination of parameters that significantly improves the LB — it consistently hovers around 0.79x.😱😱😱", "votes": null }, { "id": "3205061", "postDate": "05/19/2025 08:37:43", "content": "When generating spectrograms, do you adjust parameters (e.g., hop_length, n_fft) to align the time/frequency dimensions with your target output size before resizing?
\nCould you please share how do you approach spectrogram normalization?
", "rawMarkdown": "When generating spectrograms, do you adjust parameters (e.g., hop_length, n_fft) to align the time/frequency dimensions with your target output size before resizing? \n\nCould you please share how do you approach spectrogram normalization?", "votes": null }, { "id": "3205076", "postDate": "05/19/2025 09:28:01", "content": "1.I didn't adjust the parameters used to generate the spectrograms to match the target size. Instead, I first generated the spectrograms using the original parameters, and then applied cv2.resize to scale the spectrograms to the input size required by the model.😀
\n2.We apply log transformation to the mel spectrogram to compress its dynamic range (log(mel + 1e-6)), then normalize it using zero mean and unit variance normalization. 🥰
Since different waveform segment sampling strategies can affect model performance, I recommend saving the raw waveform data as .npy or .hdf5 files instead of precomputed mel-spectrograms to allow more flexible sampling and speed up the training process.
In my implementation, spectral parameters such as n_fft, n_mels, hop_length and top_db have shown to influence model performance more significantly than other hyperparameters.
Just wanted to say 🥰 that resizing mel-spectrograms with mismatched time/frequency axes may destroy some of the spectrogram quality and you might wanna consider this:
\nFor a 60-second audio clip at sample_rate = 32000:
$$
\n60\\ \\text{sec} \\times 32000\\ \\frac{\\text{samples}}{\\text{sec}}
\n= 1\\,920\\,000\\ \\text{samples}
\n$$
$$
\n\\text{Time steps}
\n= \\frac{\\text{Total samples}}{\\text{hop_length}}
\n= \\frac{1\\,920\\,000}{512}
\n\\approx 3750
\n$$
So your mel-spectrogram has a time dimension of ~3750 and a frequency dimension of 128 (from n_mels = 128). This division tells you “how many hops fit” in your audio, i.e. how many frames you’ll compute.
When you resize the mel-spectrogram to 128 × 128 pixels:
\nThis means:
\n\n\nEach pixel along the time axis now represents ~29 time steps
\n$$
\n
\n \\displaystyle \\frac{3750}{128} \\approx 29
\n $$
Imagine a bird call (or any other 'event' that could characterize a wildlife specimen) lasting 0.1 seconds:
\nOriginal time steps:
\n$$
\n0.1\\ \\text{sec} \\times
\n\\frac{32000\\ \\tfrac{\\text{samples}}{\\text{sec}}}
\n {512\\ \\text{samples/hop}}
\n= 6.25\\ \\text{time steps}
\n$$
\nThe call spans ~6 time steps (detectable as a distinct event).
When you resize that 3750×128 matrix down to a 128×128 image, you’re effectively linearly scaling the time axis from length 3750 to length 128.
After resizing to 128 pixels:
\n$$
\n\\frac{6.25\\ \\text{steps}}{3750\\ \\text{total steps}}
\n\\times 128\\ \\text{pixels}
\n\\approx 0.21\\ \\text{pixels}
\n$$
\nThe call (or whatever) is now smaller than 1 pixel…
By adjusting hop_length, you directly control both how many frames your mel-spectrogram has and how finely you can resolve short events in time. So maybe this requires a more careful approach. Please, correct me if I am wrong.
\nAn image to illustrate the point. Even though the original plot looks better, after resizing you get a sharper looking plot with these parameters: hop_length=(5 * 32000) // 128, # = 160000 / 128 = 1250 → exactly 128 frames (take a look at the left upper corner):
\n
Thanks so much for this detailed explanation, Alexander! 🙏 I now realize how resizing can affect time resolution, and I’ll definitely reconsider my approach to hop_length. Really appreciate it!🥰
", "rawMarkdown": "Thanks so much for this detailed explanation, Alexander! 🙏 I now realize how resizing can affect time resolution, and I’ll definitely reconsider my approach to hop_length. Really appreciate it!🥰", "votes": null }, { "id": "3205165", "postDate": "05/19/2025 11:39:56", "content": "That’s an awesome insight. Thank you for sharing it!🥳
", "rawMarkdown": "That’s an awesome insight. Thank you for sharing it!🥳", "votes": null } ], "comments": [ { "id": 3205061, "author_name": "alexandergremyakov", "author_url": "", "post_date": "05/19/2025 08:37:43", "content": "When generating spectrograms, do you adjust parameters (e.g., hop_length, n_fft) to align the time/frequency dimensions with your target output size before resizing?
\nCould you please share how do you approach spectrogram normalization?
", "votes": null, "replies": [ { "id": 3205076, "author_name": "achang0721", "author_url": "", "post_date": "05/19/2025 09:28:01", "content": "1.I didn't adjust the parameters used to generate the spectrograms to match the target size. Instead, I first generated the spectrograms using the original parameters, and then applied cv2.resize to scale the spectrograms to the input size required by the model.😀
\n2.We apply log transformation to the mel spectrogram to compress its dynamic range (log(mel + 1e-6)), then normalize it using zero mean and unit variance normalization. 🥰
Since different waveform segment sampling strategies can affect model performance, I recommend saving the raw waveform data as .npy or .hdf5 files instead of precomputed mel-spectrograms to allow more flexible sampling and speed up the training process.
That’s an awesome insight. Thank you for sharing it!🥳
", "votes": null, "replies": [] } ] }, { "id": 3205135, "author_name": "alexandergremyakov", "author_url": "", "post_date": "05/19/2025 11:05:13", "content": "Just wanted to say 🥰 that resizing mel-spectrograms with mismatched time/frequency axes may destroy some of the spectrogram quality and you might wanna consider this:
\nFor a 60-second audio clip at sample_rate = 32000:
$$
\n60\\ \\text{sec} \\times 32000\\ \\frac{\\text{samples}}{\\text{sec}}
\n= 1\\,920\\,000\\ \\text{samples}
\n$$
$$
\n\\text{Time steps}
\n= \\frac{\\text{Total samples}}{\\text{hop_length}}
\n= \\frac{1\\,920\\,000}{512}
\n\\approx 3750
\n$$
So your mel-spectrogram has a time dimension of ~3750 and a frequency dimension of 128 (from n_mels = 128). This division tells you “how many hops fit” in your audio, i.e. how many frames you’ll compute.
When you resize the mel-spectrogram to 128 × 128 pixels:
\nThis means:
\n\n\nEach pixel along the time axis now represents ~29 time steps
\n$$
\n
\n \\displaystyle \\frac{3750}{128} \\approx 29
\n $$
Imagine a bird call (or any other 'event' that could characterize a wildlife specimen) lasting 0.1 seconds:
\nOriginal time steps:
\n$$
\n0.1\\ \\text{sec} \\times
\n\\frac{32000\\ \\tfrac{\\text{samples}}{\\text{sec}}}
\n {512\\ \\text{samples/hop}}
\n= 6.25\\ \\text{time steps}
\n$$
\nThe call spans ~6 time steps (detectable as a distinct event).
When you resize that 3750×128 matrix down to a 128×128 image, you’re effectively linearly scaling the time axis from length 3750 to length 128.
After resizing to 128 pixels:
\n$$
\n\\frac{6.25\\ \\text{steps}}{3750\\ \\text{total steps}}
\n\\times 128\\ \\text{pixels}
\n\\approx 0.21\\ \\text{pixels}
\n$$
\nThe call (or whatever) is now smaller than 1 pixel…
By adjusting hop_length, you directly control both how many frames your mel-spectrogram has and how finely you can resolve short events in time. So maybe this requires a more careful approach. Please, correct me if I am wrong.
\nAn image to illustrate the point. Even though the original plot looks better, after resizing you get a sharper looking plot with these parameters: hop_length=(5 * 32000) // 128, # = 160000 / 128 = 1250 → exactly 128 frames (take a look at the left upper corner):
\n
Thanks so much for this detailed explanation, Alexander! 🙏 I now realize how resizing can affect time resolution, and I’ll definitely reconsider my approach to hop_length. Really appreciate it!🥰
", "votes": null, "replies": [] } ] } ] } ] }, { "id": 3205133, "author_name": "fangsionfang", "author_url": "", "post_date": "05/19/2025 11:02:10", "content": "In my implementation, spectral parameters such as n_fft, n_mels, hop_length and top_db have shown to influence model performance more significantly than other hyperparameters.