# **DL Sprint 4.0 — Bangla Long-Form ASR & Speaker Diarization** **Official Rulebook** **Date:** 28 January 2026 **Organized by:** BUET CSE Fest 2026 **Platform:** Kaggle --- ## **0\) Important Links** **Registration (mandatory):** [https://forms.gle/THkhuRzdmi56QBSL7](https://forms.gle/THkhuRzdmi56QBSL7) **Problem 1 — Bangla Long-Form ASR** **Problem 2 — Speaker Diarization** **Note:** Problem 1 and Problem 2 will be hosted as **two separate Kaggle competitions** (two different links). The links will be announced through our official Event Page and Facebook Page. --- ## **1\) Overview** DL Sprint 4.0 is a competitive machine learning sprint focused on **Bangla long-form audio**. The competition consists of two independent problems: * **Problem 1 (ASR):** Transcribe Bangla speech into text. * **Problem 2 (Diarization):** Identify *who spoke when* by producing speaker-wise time segments. Participants may compete in **one or both** problems. To be considered for **overall awards**, teams must submit solutions to **both problems**. --- ## **2\) Competition Phases** **Phase 1 (Part 1):** Public Leaderboard The public leaderboard will remain live throughout the competition. **Phase 1 (Part 2):** Private Leaderboard On the submission deadline, the private leaderboard will be automatically updated using the remaining portion of the test set. **Phase 2 (Part 1: Selection for Final):** Hidden Test Evaluation Final rankings will be determined using a hidden test set. The organizing committee will rerun participants’ submitted notebooks on these hidden test cases. The **top 15 teams**, based on combined public, private, and hidden test set performance, will advance to the final round. **Phase 2 (Part 2: On-Site Final Round):** In the on-site final round, shortlisted teams will be evaluated based on: * Presentation and QnA * Novelty of the approach * Submitted research paper Based on weighted performance across all phases, winners will be selected. --- ## **3\) Tasks & Required Outputs** ### **3.1 Problem 1 — Bangla Long-Form ASR (Transcription)** **Input:** Long-form Bangla audio **Output:** Predicted Bangla transcript **Submission format:** Will be specified in the live competition page. **Note:** Participants do **not** need to handle punctuation explicitly. --- ### **3.2 Problem 2 — Speaker Diarization** **Input:** Long-form Bangla audio **Output:** Speaker-wise segments containing: * Start time * End time * Speaker ID **Submission format:** Will be specified in the live competition page. **Rules for Speaker IDs:** * Speaker IDs must remain consistent **within a single audio file**. * If multiple speakers start speaking simultaneously, the **first speaker’s ID** should be assigned. --- ## **4\) Models, Training, and Compute Rules** ### **4.1 Pretrained Models** Publicly available **open-source pretrained models** are allowed, provided they are appropriately licensed. Participants must disclose: * Model name and version with repository link * License information * Claimed pretraining data (as stated by the model authors) ### **4.2 Fine-Tuning** Fine-tuning of pretrained models is permitted. ### **4.3 API Prohibition (Strict)** The use of **any external API** is strictly prohibited. This includes, but is not limited to, OpenAI, Claude, or any hosted speech/ASR services. All inference must be performed **locally within Kaggle notebooks**. ### **4.4 External Infrastructure** External infrastructure may be used for **training purposes only**. Final submissions must be **fully reproducible on Kaggle**. ### **4.5 External Data Policy** The use of external data is allowed under the following conditions: * The data must be publicly available, curated from public sources, or created during the competition runtime. * All external data must be clearly declared and made public with proper citations. * External data must **not** include or be derived from any competition test set. Participants may also create and use their own datasets. Significant contributions in this area may qualify for the **Best Dataset Award**. --- ## **5\) Submission Requirements (Reproducibility)** Each team must submit: * A **training notebook** (Preferred to be Kaggle-runnable) \- If applicable * An **inference notebook** (Must be Kaggle-runnable and capable of generating the final submission) * Model checkpoints or weights (preferably hosted on Hugging Face) * Clear documentation (README within the notebook or markdown cells) * A research paper prepared using the **IEEE Overleaf template** Teams are strongly encouraged to upload their paper to [**arXiv**](https://arxiv.org/) and submit the corresponding DOI link. **Re-run Policy:** All submissions will be rerun on both the public and hidden test sets after Phase 1 concludes. The inference notebook must execute within Kaggle runtime limits (CPU or GPU, as permitted). **Submission Limit:** A maximum of **5 submissions per day per team** is allowed for each competition. --- ## **6\) Team Formation & Eligibility** * Maximum team size: **4 members** * All team members must be undergraduate students or recent graduates (HSC 2020 batch). To ensure fairness, students from the BUET CSE 20 Batch are not eligible to participate as contestants. * No instructors or faculty members are allowed. * You should merge the team within three days after the competition is live. * Teams may consist of members from multiple institutions. * **Private code sharing outside the team is strictly prohibited.** Any team found violating this rule will be immediately banned. * **Sharing of weights of own trained or finetuned models outside the team is strictly prohibited.** Any team found violating this rule will be immediately banned. Only one Kaggle account per participant is allowed. Teams must submit solutions using their **registered team name**. Submissions from unregistered teams will not be considered for advancement. --- ## **7\) Evaluation & Scoring (Official)** ### **7.1 Overall Scoring Structure** The final score will be computed using the following weighted structure: * **Total Score** \= 70% Online Evaluation \+ 30% Offline Evaluation * **Online Evaluation** \= 30% Inference Time Score \+ 70% Model Performance Score * **Model Performance Score** \= * 20% Public Leaderboard Score * 30% Private Leaderboard Score * 50% Hidden Test Set Score * **Offline Evaluation** \= * 20% Presentation & Q/A * 20% Paper Quality * 60% Novelty All scores are normalized to a scale of **0–100**. ### **7.2 Model Performance Breakdown** Since Problem 1 and Problem 2 are hosted as separate competitions, each phase score is calculated as the **average** of both tasks. * Public Phase Score \= Average of ASR and Diarization public scores * Private Phase Score \= Average of ASR and Diarization private scores * Hidden Phase Score \= Average of ASR and Diarization hidden scores **Metric Conversion:** * ASR is evaluated using **Word Error Rate (WER)** * Diarization is evaluated using **Diarization Error Rate (DER)** Lower error rates correspond to higher scores using the standard conversion: Score \= 100 × (1 − Error Rate) --- ## **8\) Inference Time Evaluation** ### **8.1 Measurement Protocol** Inference efficiency will be measured using **Real-Time Factor (RTF)**. * Total duration of benchmark audio \= D seconds * Total inference time \= T seconds * Real-Time Factor \= T ÷ D A lower RTF indicates faster inference. ### **8.2 Inference Time Scoring** Inference time scores are computed relative to the fastest valid submission. Faster models receive significantly higher scores to encourage efficiency. The scoring procedure is defined as follows: * **RTF Averaging** For each participant, the RTF is computed for every test case. The final RTF for a participant is the **average RTF across all test cases**. * **Ranking and Percentile Assignment** The set of average RTFs from all valid participants is collected. Participants are ranked based on their average RTF, where **lower RTF corresponds to better performance**. Percentile ranks are then computed over this ordered set. * **Score Mapping** Percentile ranks (in ascending order of RTF) are directly mapped to inference time scores. For example: * Participants in the 1st percentile receive a score of 100 * Participants in the 2nd percentile receive a score of 99 * Participants in higher percentiles (higher RTF, higher inference time) receive proportionally lower scores. This percentile-based scoring ensures that inference efficiency is evaluated relative to competing submissions and that performance gains in speed are meaningfully rewarded. --- ## ## ## **9\) Offline Evaluation Criteria** ### **9.1 Presentation & Q/A (20%)** Judged based on: * Clarity of explanation * Sound experimental design * Ability to answer technical questions * Reproducibility and transparency ### **9.2 Paper Evaluation (20%)** The submitted paper will be assessed on: * Clear pipeline description * Model and training details * Experimental results and comparisons * Limitations and ethical considerations * Benchmarking against existing approaches (mandatory) ### **9.3 Novelty Assessment (60%)** Novelty is the most heavily weighted offline criterion. Higher scores will be awarded for: * Novel Architecture beyond existing ones * New Approaches that improve accuracy and/or inference efficiency * Exploratory attempts and findings will also be considered in the evaluation of novelty. --- ## **10\) Originality and Code of Conduct** All submitted work must be original. Copying private solutions, sharing code outside teams, or plagiarizing prior work will result in disqualification. ### 10.1\) Mandatory Open-Source Contribution To support reproducible research and community progress, teams selected for the final round must publicly release their final solution after the competition ends, including code, inference pipeline, and documentation, under an open-source or Creative Commons license of their choice. Teams must also provide a public link to weights and detailed instructions for reuse. --- ## ## **11\) Prohibited Actions** Immediate disqualification may occur for: * Using any prohibited API or online inference service * Manually labeling or transcribing the test set * Submitting non-reproducible solutions Participants must submit the **same notebook** that produced their Phase 1 leaderboard score. If significant mismatches are detected (beyond expected model variability), the organizing committee reserves the right to disqualify the submission. ## **11\) Terms and Conditions** Organizers reserve the right to modify the rules at any time during the competition. --- ## **12\) Contact Information** **Email:** dlsprint@buetcsefest2026.com **Phone:** Shadman Tabib — \+8801880198766 Istiak Ahmmed Rifti — \+8801776039843 Abdullah Muhammed Amimul Ehsan — \+8801867850970 Anik Saha — \+8801531949133