Draft
Conversation
Copilot
AI
changed the title
[WIP] Add new feature module to application
Request clarification on requirements
Feb 3, 2026
sk413025
pushed a commit
that referenced
this pull request
Feb 23, 2026
- §2.1: Reframe experiment goals as "blocking breaks MIC-MIC → LDV rescues" - §13: Rewrite from "prior strategy test" to "LDV rescue effectiveness" - Add clear explanation: MIC-MIC estimates speaker direction, LDV estimates v-point direction - Define MIC-MIC Oracle vs LDV Oracle with different references - Add four-level comparison table (MIC-MIC global/oracle + LDV S2/oracle) - Add MIC-MIC Oracle data: block-3 rank #2 (0.42°), block-2 rank #13 (6.32°) - §10.10: Add MIC-MIC Oracle column, clarify spk vs vpt references - §15.1: Restructure conclusions with rescue narrative as primary - §15.2: Add MIC-MIC Oracle column to tracking table, add reference annotations - §15.3-15.4: Update theory assessment and recommendations Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
sk413025
pushed a commit
that referenced
this pull request
Feb 23, 2026
First negative-angle analysis: - Unblock MIC-MIC: err=1.97° (good baseline) - Block MIC-MIC: err=34.48° (blocking adds +32.5° error) - Block MIC-MIC Oracle: err=5.90° (rank #2, correct info exists) - LDV S2: vs speaker err=0.77° but WARNING: S2 selected negative-lag non-physical peaks whose Δτ coincidentally matches speaker TDOA - LDV Oracle: v=(+0.18,0.50) gives err=8.57° (doesn't fit) Oracle scan finds v_x=-0.21 with err=0.09° → different LDV spot position - Correct peaks ranked #250/#352 → auto selection very difficult Key finding: block-6 LDV spot position (v_x≈-0.21) differs from block-4/5 (v_x≈+0.18), likely due to different experiment session. Decoupling formula correct in both cases (Oracle err <0.1°). Updated tracking table: -0.4m now complete, only -0.8m remaining. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
sk413025
pushed a commit
that referenced
this pull request
Feb 24, 2026
…ntial
Background
----------
S3-joint achieves MAE=1.48° but requires spk_x as input (to compute
theoretical delays and narrow the search window). We tested whether
a blind 2D grid search over vibration-point x-coordinate (with the
same ±0.5ms windowing constraint) can work without this prior.
Implementation: S3-joint-2D
----------------------------
For each candidate vx in [-1.2, 1.2] at 0.005m steps (vy fixed at
BOARD_Y=0.25):
1. Compute theoretical τ_VL, τ_VR from v=(vx, 0.25)
2. Find peak near each theoretical delay (±0.5ms window)
3. Score = a_VL + a_VR
4. Best vx → compute angle two ways:
- θ_naive: from Δτ (same as S3-joint)
- θ_source: from (vx, 0) to mics (parallax correction)
Results
-------
Method MAE
S3-joint 1D (with spk_x hint) 1.48°
S3-2D naive (blind, vibration-point angle) 32.08°
S3-2D source (blind, source@y=0 correction) 28.05°
Estimated vx vs true spk_x:
spk_x=-0.8m → vx=-0.075 (dx=+0.725, completely wrong)
spk_x=+0.0m → vx=-0.930 (dx=-0.930, completely wrong)
spk_x=+0.8m → vx=-0.845 (dx=-1.645, completely wrong)
Root cause
----------
The ±0.5ms window constraint, when applied blindly to wrong vx
candidates, still finds spurious peaks from structural multipath.
These spurious peaks often have HIGHER amplitudes than the true
peaks at the correct vx, because the barrier's multipath pattern
creates strong coherent artifacts at certain (wrong) delay pairs.
S3-joint's success depends critically on TWO ingredients:
1. The ±0.5ms narrow window (filters multipath)
2. The spk_x prior (centers the window on the correct delays)
Without #2, the window centers on wrong delays and picks up noise.
This is NOT a grid resolution issue — the grid is dense (0.005m).
It's a fundamental signal quality issue: the GCC-PHAT landscape
has stronger false peaks than true peaks across most of the search
space.
Implication for PI-DNN
-----------------------
This explains why ALL unsupervised approaches fail:
- Physics-only GD: trapped by false peaks (MAE=18.59°)
- S3-2D blind: finds wrong vx (MAE=28-32°)
- PI-DNN LOO-CV: memorizes angles, can't generalize (MAE=17.5°)
The ONLY working approach is S3-joint with spk_x knowledge, which
in a real deployment means having approximate prior knowledge of the
source direction.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem statement provided ("hi") does not contain actionable requirements or specifications.
Current State
full_analysis.py) processes acoustic dataGCC-PHAT_LDV_MIC_完整實驗報告.md)Action Needed
No changes implemented pending clarification on:
Please provide detailed requirements to proceed with implementation.
Original prompt
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.