رَتِّلِ ، تطبيق بسيط يُلقّنك ويَصِل ما تحفظ بما قبله

محمد إدريس

السلام عليكم ورحمة الله وبركاته،

قرأت طرح بشمهندس أحمد شمس عن التكرار الدائري المتقاطع في هذا الموضوع: https://community.itqan.dev/d/432، وقرأت النقاش الذي دار تحته، وأحببت أن أجرّبها عمليًا في تطبيق صغير اسمه رَتِّلِ.

التطبيق: https://edriso.github.io/rattil/
الكود مفتوح: https://github.com/edriso/rattil

كيف تمشي الجلسة؟

تختار السورة، ومن أي آية إلى أي آية، ثم تمشي الجلسة على ثلاث خطوات متكرّرة:

تلقين: يُسمعك المقطع الجديد وحده حتى يستقرّ.
وصل: يضمّه إلى ما قبله ويعيدهما معًا، فتتمرّن على موضع الالتحام نفسه، وهو الموضع الذي ينقطع عنده الحافظ عادةً.
سرد: يُقرأ المقطع كاملًا في آخر الجلسة.

وبعدها تُقيّم سردك، فيُجدوَل المقطع للمراجعة على جهازك.

ما أخذته من النقاش

الوصل بالمقطع أو المقطعين السابقين، لا من أول المقطع في كل مرة، حتى لا تطول الجلسة بلا فائدة.
تقسيم الآية الطويلة عند علامات الوقف فقط، ويُقصّ الصوت عند الموضع نفسه، فلا تُقتطع كلمة.
سكتة الترديد بقدر المقطع لا برقم ثابت، فتطول مع الآية الطويلة.
تقدير زمن الجلسة وعدد التكرارات قبل أن تبدأ، فإن طالت خفّفتَ التكرار أو ضيّقتَ المدى.
تسعة قرّاء بسرعات مختلفة، وتقسيم بالجملة أو الآية أو كتلة آيات.

وكل شيء يعمل داخل المتصفح: لا حساب، ولا خادم، ولا يُرفع شيء. وما تسجّله من صوتك يبقى على جهازك ويُحذف عند انتقالك.

جزا الله خيرا

أحمد شمس على الطرح، ولكل من شارك في النقاش مع حفظ الألقاب: رقية، وعلا، وعادل، ومَيادة فملاحظاتهم هي التي شكّلت أكثر تفاصيل التطبيق. وللأخ علي ملص، فتطبيق تواتر كان أول نموذج عملي للفكرة واستفدتُ منه.

إذا جربت التطبيق برجاء إخبارنا بكيف تُفضل تحسينه، : هل التكرار يكفي أم يزيد؟ وهل الوصل بمقطعين مناسب لكم؟ أي ملاحظة تنفعنا بإذن الله

وجزاكم الله خيرًا

دينا أحمد

جزاك الله خيرًا يا م. محمد، شغل متقن ومدروس فعلًا

أعجبني جدًا أنك لم تكتفِ بأخذ فكرة التكرار الدائري المتقاطع، بل ترجمت كثيرًا من الملاحظات التي طُرحت في النقاش إلى تفاصيل عملية داخل التطبيق.

فتقسيم النص بالجملة يعتمد على علامات الوقف، والقطع الصوتية مُولّدة مسبقًا ومحفوظة داخل المستودع، مع انتهاء كل جزء عند بداية الكلمة التالية لا في منتصفها، وبالتالي لا تضيع كلمة من الآية. وهذا تحديدًا حلّ ملاحظة علا صالح التي ظهرت في نقاش «تواتر».

وكذلك فكرة «مقاطع الوصل» التي تكتفي بضم مقطع أو مقطعين سابقين بدل العودة إلى بداية السورة في كل مرة، وهي نفس الفكرة التي اقترحتها رقية بورية، وقد أعجبني أنك جعلتها جزءًا من تصميم الجلسة نفسه بدل تحويلها إلى خيار إضافي يحتاج المستخدم إلى ضبطه.

وفي خطة المراجعة أيضًا تفصيلة ذكية تستحق الإشادة: وضع حد أدنى لمعامل السهولة في خوارزمية المراجعة. لأن انخفاض المعامل كثيرًا مع التقييمات الضعيفة المتتالية قد يؤدي إلى تقليص الفاصل بين المراجعات باستمرار، بينما وجود هذا الحد يمنع المدة من الانهيار إلى مراجعة شبه يومية للمقطع نفسه.

ملاحظة واحدة بعد التجربة: عدد مرات التكرار (تلقين / وصل / سرد) موجود حاليًا داخل الإعدادات بشكل منفصل، وأرى أن وجوده في الشاشة الرئيسية بجانب بقية خيارات الجلسة سيكون أسهل؛ لأنه من الأشياء التي قد يرغب المستخدم في تعديلها مباشرة كلما شعر أن الجلسة أطول أو أقصر مما يناسبه.

وفي تفصيلة صغيرة أعجبتني أيضًا: كتابة سرعة القارئ (متأنٍّ / معتدل / سريع) بجانب اسمه قبل الاختيار. إضافة بسيطة، لكنها توفر على المستخدم تجربة القراء واحدًا واحدًا للوصول إلى السرعة المناسبة.

بارك الله فيك، وشكرًا على هذا التطبيق الجميل وعلى تحويل نقاش المجتمع إلى تجربة عملية يمكن تجربتها والاستفادة منها 🌿
محمد إدريس

علي ملص

محمد إدريس

عمل ممتاز، ولدي سؤال: ما بيانات التزمين حسب الوقف التي اعتمدتها؟ لأن المقطع يقطع قبل انتهاء نفس القارئ في بعض الأحيان حتى عند اختيار التقسيم حسب النفس (الجملة)، مثل نهاية هذا المقطع:

وهذه المشكلة عانيت منها عند إعداد برنامج شبيه، إذ لم أجد بيانات تقسيم حسب النفس.

أعتقد من الضروري في هذا النوع من التطبيقات أن يكون التقسيم حسب الوقف، ويجب على مصادر البيانات القرآنية أن توفر بيانات توقيتات الوقف للتلاوات.

هل يتضمن فنار هذه البيانات بحيث يمكن استخدامه في التطبيق شيخ أحمد؟ @أحمد شمس

محمد إدريس

بفضل الله تم وضعه على هذا النطاق
https://darhifz.com/

مقارب ل اسم نطاق
https://dartajweed.com/

أحمد شمس

تسلم ايدك يا بطل جزاك الله خيرا
هنا يطرأ على بالي سؤال
هل يمكن أن يستفيد أي تطبيق من هذا الجهد بدمج المحرك الذي تفضلت بإنتاجه
وما هي البنية التحتية اللازمة لذلك
على سبيل المثال أرجو أن توضح أنك استخدمت مثلا مصحف الحصري من المصدر الفلاني وهو مع قواعد بيانات تزمين على مستويات متعددة كذا وكذا وتضع طريق للوصول لهذا المحتوى مع حواشيه من قواعد بيانات
حتى يتمكن من يحب الاستفادة من عملك من نقل الفكرة وتطبيقها والبناء عليها

وعلى فكرة ليس من الضروري أن يكون التكرار هذا مطبقا على كل المصاحف وهذا رأيي الشخصي بل لابد أن يكون مركزا على المصاحف التعليمية للقراء المتقنين المهرة مثل الحصري والبنا وأيمن سويد وغيرهم
على كل حال جزاك الله خيرا

أحمد شمس

كان عندي سؤال أخير هل المقصود بالاختيارات تحت نطاق الآيات المحدد يدويا هو عدد التكرارات؟

لو كان كذلك فالمسمى موهم ينبغي أن يسمى 3 مرات أو تكرارات أو ما شابه

أبو بكر عبد الرحمن

@محمد إدريس Loaded rattil with Fatiha still on the default three ayahs. Start row already had نحو ١٢ دقيقة and ٤٧ مرة on it, from the per-letter reciter table, before any mp3 came down. The جملة switch is on that same screen too. آية الكرسي in the README goes from one unit at about nine minutes to seven at about twenty-seven if you split on waqf.

هادي الأحمد

الله يعطيك العافية يا مهندس محمد ويتقبل منك، الواجهة من ألطف ما رأيت في الفترة السابقة، ربما تشاركنا تجربتك في تصميم هذا النوع من الواجهات وموضوع اختيار الخطوط والألوان في وقت لاحق في المجتمع، فكلّنا بحاجة لهذا النوع من المعرفة :D

أحمد شمس

نحن في إتقان بالتعاون مع الأفاضل أمثالك نبني منجم ليتفادى هذه المشكلة في التزمينات المنتجة به
لو تذكر يا باشمهندس @علي ملص ونحن نختبر بيئة عمل منجم
قلت لكم لا ينبغي أن نعطي الاهتمام للتعرف على زمن الكلمة قدر ما نعطي اهتماما للتعرف على الآية والجملة
وقصدت بالجملة الجملة التي يقف عليها القارئ أثناء تلاوته دون أي عملية بتر للصوت
وغالبا وقوف القارئ تكون وقوف معتمدة أو وقوف اضطرارية فيها إعادات بين الجمل
المحصلة في الأخير جمل لها بداية ونهاية بدون بتر للصوت

التعرف على الكلمة يمكن أن يكون تقريبي ولا يستخدم أبدا في بتر التلاوات المسترسلة وإنما يستخدم للتمميز اللوني وهذا لن يفرق فيه لو دمج زمن كلمتين في كلمة

وهذا مشاهد في التتبع البصري في ترتيل وفي تطبيق الكتاب كذلك

كما طالبت أن يعتبر زمن بداية الآية هو نفسه زمن بداية الآية السابقة لها وزمن نهايتها هو زمن بداية الآية التالية مع إزاحة زمنية قبل البدء مقدارها ٢٠٠ ملي سكند لنضمن عدم بتر صوت بدء الكلام

المحصلة لو قدرنا أن نوفر بيانات تزمين نظيفة مبنية على رؤوس الآيات أو رؤوس الجمل بيكون عندنا محتوى نظيف خالي من البتر والقطع للصوت الموصول

خالد بن أحمد

فكرة رائعة ومميزة.

لو جعلت اختيار الآية يكون من خلال قائمة منسدلة وتعرض رأس الآية، فأظن التجربة ستكون أسهل بإذن الله.

جزاكم الله خيرا

محمد إدريس

جزاكم الله خيرًا جميعًا على ملاحظاتكم واهتمامكم بتطبيق «رَتِّل». استفدت كثيرًا من اقتراحاتكم، والحمد لله تم تحسين عدد من الأمور في التطبيق، منها تقسيم التلاوة، وإظهار مرات التكرار، وتسهيل اختيار الآيات، وإضافة قرّاء جدد، وتحسين الإيقاف والواجهة.

كما تم توضيح طريقة عمل التطبيق ومصادره في المستودع، وإضافة ترخيص يسمح بالاستفادة من الكود والبناء عليه بسهولة.

بقيت بعض الأمور التي تحتاج إلى تحسين، خصوصًا دقة تقسيم التلاوة عند مواضع الوقف، وبإذن الله نستمر في العمل عليها.

شكرًا لكل من جرّب التطبيق وكتب ملاحظته. كثير من هذه التحسينات ما كانت لتحدث لولا هذا النقاش الطيب. جزاكم الله خيرًا ونفع بكم ورضى عنكم.

@دينا أحمد @علي ملص @أحمد شمس @أبو بكر عبد الرحمن @خالد بن أحمد @هادي الأحمد

إذا وجدت أي خطأ او تحسين لا ترددوا أن تبلغونا، بارك الله فيكم

محمد إدريس

التفصيلة أيضا كانت من اقتراح من استاذة @Mayada Helmy جزاكم الله خيرا

محمد إدريس

جزاك الله خيرا بشمهندس هادي، أخوك محمد على طول بارك الله فيك ورفع قدرك
فعلا في العادة التطبيقات بإستخدام claude code مثلا أشعر انها مماثلة، لهذا ذهبت هذه المرة إلى شات gpt وكتبت له prompt بالعربية والإنجليزية وطلبت منه ان يكتبها لي بالإنجليزية
واخذت هذا البرومت إلى موقع lovable

بعدها هذا الموقع اقترح علي ٣ اختيارات، اخترت واحد منهم وطلبت منه تعديلات

بعدها أرسل إلي البرومت في حالة أني أردت عمل أي تعديلات أخرى
وعندما وافقت وكان يعمل على التطبيق، الجلسة المجانية اليومية انتهت

كان هدفي اني اخذ الكود منه وأعيد بناءه ب claude او codex

يتبع...

محمد إدريس

كان هذا هو ال prompt من lovable
"# رِتِّل — Arabic Quran Memorization App

A single-page, Arabic (RTL), mobile-first app for memorizing the Quran, in the dark obsidian style you picked (deep charcoal, warm cream text, a single gold accent) — pared down: centered single column, and everything optional hidden behind a settings button.

The screen

One page, one centered column. Three states that flow into each other:

1. Start (before you begin)

Choose a Surah (all 114, searchable in Arabic).
Optionally choose a starting Ayah — defaults to 1.
One button: ابدأ الحفظ.

2. Memorizing

The picker collapses into a slim top bar showing "سورة النور · آية ٩" — tapping it reopens the picker to change position.
One ayah at a time, large and centered in open space. (Number of ayahs shown at once is adjustable in settings.)
Beneath it: play the reciter, repeat, next/previous ayah.
A record button so you recite it yourself, then play your recording back and compare it to the reciter, with a small live waveform.
A hide/reveal control to test yourself before moving on.

3. Settings (single gear button in the top bar, opens a sheet)

Reciter — pick the Qari.
Theme accent color — a few swatches.
Display mode — Quran as text, or as the scanned Mushaf page image.
Ayahs per screen — 1 by default, can be raised.

Everything is in Arabic, right-to-left, with no English labels.

Memory across refreshes

Your current Surah, ayah position, and all settings are saved on the device, so reloading drops you exactly where you left off with the picker already collapsed. Voice recordings stay in the browser session only — never uploaded.

Mobile-first details

Designed at phone width first: single centered column, comfortable tap targets, controls within thumb reach under the verse; widens gracefully on desktop with a capped max-width.
Surah picker and settings open as bottom sheets on phones, side panels on wider screens.
Verse text scales with screen size so it never crowds the edges.

Technical notes

Quran text, surah list, and per-ayah reciter audio from the free AlQuran Cloud API (api.alquran.cloud); Mushaf page images from the standard QuranComplex/quran.com image endpoints. No backend or database needed.
Self-recording uses the browser's MediaRecorder with microphone permission; audio lives in memory (object URLs), not persisted.
Progress + settings persisted in localStorage (surah, ayah, reciter, theme, display mode, ayahs-per-view), read after hydration to avoid SSR mismatch.
One TanStack route at / (replacing the placeholder index), with small components for the picker, ayah view, audio/record bar, and settings sheet.
Colors as semantic oklch tokens in src/styles.css; the theme swatch swaps the accent token — no hardcoded colors in components.
Amiri for Quran text, Reem Kufi / IBM Plex Sans Arabic for UI, loaded via <link> in the root route head.
Route head() gets an Arabic title/description and social tags.
"

يتبع ...

محمد إدريس

وقد شاء الله لي أن أحصل على صلاحية على chatgpt codex و المودل الجديد Astra
ف طلبت منه عمل الجزء الخاص بالبناء والواجهة الأمامية

وبعدها استخدمت claude opus xhigh بفضل الله في باقي المشروع والمحتوى والتعديلات

ف بفضل الله كنت أركز على
mobile first design
minimal, clean, accessible, easy to use design
والحمدلله ظهرت هذه النسخة : )

في الأول كانت الكلام في الصفحة أكثر من ذلك ف كنت اطلب منه ان يزيل ما ليس مهم ليصبح التصميم أبسط...

جزاك الله خيرا على ملاحظتك وأتمنى أن تكون الإجابة مفيدة

محمد إدريس

وأيضًا حاولت أن تكون قواعد الواجهة بسيطة وواضحة، حتى يسهل الحفاظ عليها أو البناء عليها لاحقًا:

الخطوط ثلاثة، ولكل واحد وظيفة واضحة:
أميري للنص القرآني، وIBM Plex Sans Arabic للواجهة، وReem Kufi لاسم التطبيق فقط. والهدف أن يكون النص القرآني مميزًا بصريًا عن بقية الواجهة، حتى عند المرور السريع بالعين.

أما الألوان فكلها مبنية على نظام واحد.
التطبيق يدعم المظهر الفاتح والداكن والتلقائي، مع أربعة ألوان رئيسية، وكل ذلك باستخدام متغيرات CSS، بحيث يمكن تغيير اللون من مكان واحد دون ملاحقة القيم في الملفات.

والأهم أن التباين لم أعتمد فيه على النظر فقط، بل قسته فعليًا: 4.5:1 للنص في جميع تركيبات الألوان والمظهرين، و3:1 لحدود العناصر التفاعلية بحسب WCAG 1.4.11.

وقد اكتشفت بهذه الطريقة نصًا صغيرًا كان يفشل في الحالات الثماني كلها، مع أنه لم يكن يبدو سيئًا بالعين. لذلك أصبحت القاعدة عندي: التباين يُقاس ولا يُقدَّر. ولهذا أيضًا منعت استخدام opacity لإخفات النص، لأنها قد تخفض التباين مع الخلفية دون أن يكون ذلك واضحًا.

وبالنسبة لطول الشاشة، فهناك قاعدة واحدة تتحكم في المسافات.
الشاشة الأولى تستخدم متغيرًا واحدًا اسمه --gap، وتقل المسافات تدريجيًا كلما قصرت الشاشة، عبر أربع مراحل.

وفي أقصر الشاشات يُخفى العنوان بصريًا فقط، مع بقائه في شجرة الوصول، لأن اسم التطبيق الموجود في الزاوية يكفي. وهذا يوفر نحو 70 بكسلًا يمكن الاستفادة منها لبقية عناصر الواجهة.

لكن هناك قاعدتان لا تتغيران: لا نحذف أي صف من الوظائف، ولا تقل مساحة اللمس لأي عنصر عن 44 بكسلًا.

وقست هذا كله فعليًا في المتصفح على سبعة أطوال مختلفة للشاشة، ودوّنت النتائج في المستودع، حتى لا يضطر من يأتي بعد ذلك إلى إعادة هذه القياسات من الصفر.

وأضفت أيضًا دليلًا مبسطًا للمساهمة في المشروع:
docs/CONTRIBUTING.md

كتبته بحيث يفهمه حتى من لم يطّلع على الكود من قبل أو لا يقرأ العربية، ولعلّه يفيد أيضًا من يريد بناء تطبيق مشابه.

محمد إدريس

جزاك الله خيرًا أخي خالد، وقد أخذت باقتراحك فعلًا.

اختيار الآية أصبح من قائمة منسدلة تعرض بداية الآية في طرفَي المقطع، مع إمكانية البحث بكلمات الآية أو كتابة رقمها مباشرة، سواء بالأرقام العربية أو اللاتينية.

وأثناء تنفيذ الاقتراح ظهر عيب مهم في الحقول القديمة. كان الحقل لا يقبل أن يفرغ، ثم عند السماح بذلك ظهر أن التطبيق يحدّث المدى مع كل ضغطة مفتاح، وهذا قد يغيّر الرقم أثناء الكتابة. فمثلًا من أراد كتابة 12 قد ينتهي به الأمر إلى 52.

لذلك أصبح كل حقل يحتفظ بما يكتبه المستخدم حتى ينتهي منه ويترك الحقل، ثم تُحدَّث قيمة المدى الفعلية. وأضفت اختبارًا يكتب الرقم خطوة خطوة حتى لا تعود المشكلة.

فجزاك الله خيرًا، اقتراحك حسّن الاختيار وكشف مشكلة لم تكن ظاهرة من قبل.

محمد إدريس

جزاك الله خيرًا أخي أبو بكر، ووصفك دقيق، وأشكرك على أنك جرّبتَ ثم كتبتَ ما رأيت بالأرقام.

نعم: التقدير يظهر قبل نزول أي ملف صوتي، لأنه محسوب من جدول «ثانية لكل حرف» لكل قارئ، وهو قياس فعلي على المصحف كامله، ثم يُصحَّح من الأطوال الحقيقية كلما وصلت. وخيار «جملة» في الشاشة نفسها كما ذكرت. ومرات التكرار صارت في الشاشة نفسها أيضًا بعد ملاحظات الموضوع.

وأمّا آية الكرسي فأصحّح رقمًا واحدًا من كلامك، وهو تصحيحٌ لصالح ما قلتَه لا ضدّه: صارت ست جمل لا سبعًا، لأن القطع لم يبق إلا عند ۚ و ۗ و ۘ، وسقط ما كان عند ۖ. فهي تنتقل من وحدة واحدة في نحو ٩ دقائق إلى ست وحدات في نحو ٢٧ دقيقة. وعلى المصحف كله: ٤٦٧٦ آية من ٦٢٣٦ لا موضع قطع فيها أصلًا، فهي واحدة في الحالتين، ومنها سورة الإخلاص وأوائل سورة البقرة؛ فالفرق بين «جملة» و«آية» لا يظهر إلا في الطوال.

محمد إدريس

جزاك الله خيرًا أخي علي، والمقطع الذي أرفقته وضّح أصل المشكلة فعلًا.

الجواب المختصر: كنت أعتمد على تزمين الكلمات في Quran.com، لكنه لا يكفي لتقسيم التلاوة حسب الوقف أو النفس.

المشكلة كانت من جهتين:

الأولى في قاعدة التقسيم عندي.
كنت أقطع عند ۖ، مع أن القارئ كثيرًا ما يصل فيها، وكنت أستخدم أيضًا بعض «كلمات الجمل» كمواضع قطع، لكن القياس أظهر أنها لا تدل على وقفة حقيقية. لذلك حذفت الحالتين، وأصبح القطع الآن فقط عند ۚ وۗ وۘ.

الثانية في بيانات التزمين نفسها.
بعد قياس آلاف الانتقالات بين الكلمات، ظهر أن السكتات لا تكون فراغًا واضحًا بين كلمتين، بل تكون غالبًا محسوبة داخل مدة إحدى الكلمات. لذلك لا يمكن استخراج موضع الوقف من تزمين الكلمات وحده.

وللتأكد، حللت 390 ملفًا صوتيًا لثلاثة قراء باستخدام ffmpeg silencedetect. وظهر أن السكتة الحقيقية تبدأ بعد الحد الموجود في التزمين بنحو 290ms عند الحصري، و400ms عند عبد الباسط، و645ms عند المنشاوي. وكان الصوت لا يزال مستمرًا عند أغلب مواضع القطع القديمة، وهو ما ظهر في المقطع الذي أرسلته.

لذلك عدلت التنفيذ ليؤخر القطع بنحو 300ms، ويحافظ على السكتة الطبيعية بين المقاطع المتتالية، ويبدأ التشغيل من أول صوت فعلي في المقطع.

وأتفق معك أن التقسيم حسب الوقف الفعلي مهم جدًا في هذا النوع من التطبيقات. الأفضل أن تتوفر توقيتات الوقف لكل تلاوة من المصدر نفسه، وقد ذكر م. أحمد شمس أن هذا من أهداف «منجم».

إلى أن تتوفر هذه البيانات، فالخطوة الأدق هي تحليل الصوت مسبقًا واستخراج السكتات الحقيقية لكل قارئ، ثم حفظها كبيانات ثابتة. شرحت التفاصيل هنا:

data/README.md

وكل بيانات القياس التي جمعتها متاحة لك إن نفعتك. وقد استفدت أنا من «تواتر» كثيرًا، فجزاك الله خيرًا عليه.

محمد إدريس

جزاك الله خيرًا شيخ أحمد، وبارك الله فيكم وفي «منجم». أجيبك عن النقاط الثلاث باختصار:

١) هل يمكن لتطبيق آخر الاستفادة من المحرّك؟

نعم، ولا يحتاج إلى خادم أو قاعدة بيانات أو حساب مستخدم. التطبيق يعمل في المتصفح، والحفظ محلي عبر localStorage.

أضفت في الـ README قسمًا بعنوان «البناء على هذا العمل» يوضح مصادر النص والصوت والتزمين، وكيف تُخزّن البيانات وتُستخدم. كما أن ملفات المحرّك منفصلة عن الواجهة، لذلك يمكن إعادة استخدامها في تطبيق آخر.

هناك شرطان مهمان عند استخدام مصدر صوت مختلف: أن يدعم access-control-allow-origin، وأن يتوافق الملف الصوتي مع بيانات التزمين.

وأضفت أيضًا ترخيص 0BSD لما كتبناه في المشروع، أما البيانات الخارجية فتراخيصها الأصلية موضحة في NOTICE.

٢) مصاحف المتقنين والمصاحف التعليمية

أضفت أيمن سويد، والمنشاوي المجوّد، وعبد الباسط المجوّد، والحصري المعلّم موجود من قبل.

بعض القراء مثل محمود علي البنا وعبد الله بصفر وعلي الحذيفي ومحمد أيوب لم أتمكن من إضافتهم لعدم توفر تزمين كلمات مناسب.

ووجدت مشكلة مهمة في المنشاوي المعلّم: بيانات التزمين موجودة، لكنها تخص تسجيلًا مختلفًا عن ملف الصوت المستخدم. لذلك أضفت تحققًا آليًا يقارن التزمين بأطوال الملفات ويرفض البيانات غير المتوافقة.

٣) عبارة «٣ آيات»

معك حق، وكانت موهمة. أصبح اسمها الآن «طول المدى»، وأصبح التكرار تحت عنوان مستقل هو «مرات التكرار».

وبخصوص الإزاحة الزمنية

ملاحظتك كانت صحيحة. بعد قياس 390 ملفًا صوتيًا، ظهر أن تزمين الكلمات وحده لا يكشف السكتة الحقيقية، لأنها غالبًا تكون داخل مدة الكلمة نفسها.

لذلك أصبح القطع متأخرًا بنحو 300ms، مع الحفاظ على السكتة الطبيعية بين المقاطع.

لكن الحل الأدق على المدى البعيد هو استخراج مواضع الوقف من الصوت نفسه مسبقًا وحفظها كبيانات ثابتة.

وهنا تحديدًا أرى فائدة كبيرة لـ«منجم»: لو وفر تزمينًا لمواضع الوقف الفعلية لكل قارئ وتسجيل، فلن يحتاج كل تطبيق إلى استنتاجها بنفسه.

وضعت تفاصيل القياسات والطريقة هنا:

data/README.md

والبيانات التي جمعتها متاحة لكم إن نفعتكم.

بارك الله فيكم وفي «منجم»، ونفع بكم.

الصفحة التالية »

ثبت مجتمعنا كتطبيق لتجربة افضل

انضم إلى نشرة إتقان 📩

انضم إلى نشرة إتقان 📩

شكراً لك!