THMMY.gr

Γνωρίζει κανείς πότε είναι η προθεσμία της εργασίας;

νομίζω είπε κάπου μετά την εξεταστική

Για τον αποκωδικοποιητή επιπέδου 1,  γινεται να υπολογίσω το s0 μονο απο τα LARc , χωρίς να χρησιμοποιήσω το d' (PrevFrmResd)?  Ρωτάω γιατι λεει οτι οι μεταβλητές () δεν εχουν νοημα στο 1ο επιπεδο που το καταλαβαινω για τον κωδικοποιητή, αλλά στην αντίστροφη διαδικασία δεν τα χρειαζόμαστε?

κι εγώ ακριβώς την ίδια απορία έχω. Και θεωρώ πως το δεύτερο όρισμα της
RPE_frame_ST_decoder
θα έπρεπε να λεγόταν CurrFrmResd και όχι PrevFrmResd

Στην εκφώνηση της εργασίας λέει ότι η εργασία θα γίνει σε ομάδες των δύο ατόμων.

Ισχύει όντως αυτό; Και αν ναι υπάρχει κάποιος που ψάχνει δεύτερο άτομο;

Εγώ έστειλα και μου είπε και μόνος σου δεν υπάρχει θέμα

Όσον αφορά την μετατροπή των συντελεστών a_k στους συντελεστές ανάκλασης r(i) χρησιμοποιώ την poly2rc ως εξής:
Ωστόσο παίρνω και τιμές που βρίσκονται και εκτός του διαστήματος [-1, 1] σε αντίθεση στο πρότυπο γράφει ότι πρέπει να βρίσκονται εντός αυτού του διαστήματος.
Καμιά ιδέα τι μπορεί να γίνεται λάθος και τι χρειάζεται για να κάνουμε σωστά τη μετατροπή;

Αν δεν κάνω λάθος υπεύθυνος για απορίες σχετικά με την εργασία είναι ο perukas που ήταν και στην Γραφική πέρυσι.

Μήπως έχει να κάνει με το πως γίνεται ο υπολογισμός του a? Γιατί (τουλάχιστονμε το notation της εργασίας) η poly2rc() παίρνει ως όρισμα τo a = [1; -w] (ίδιο προφανώς με την υλοποίησή σου). Παρ' όλα αυτά το w βγαίνει απο το (ή σε μάτλαμπ inv(R) * r). Μήπως σε αυτούς τους υπλογισμούς γίνεται κάτι λάθος?

Να ενημερώσω ότι η τελική ημερομηνία υποβολής της εργασίας είναι μία εβδομάδα μετά το τέλος της εξεταστικής, δηλαδή στις 4 Μαρτίου.

Αντί του inv() χρησιμοποιώ τον τελεστή \ και εκεί ήταν το λάθος επειδή τα είχα ανάποδα, δηλαδή w = r\R (λάθος) αντί για w = R\r (σωστό).
Τώρα οι συντελεστές φαίνεται να βγαίνουν καλοί.

Μια άλλη ερώτηση τώρα όσον αφορά τον κβαντισμό των LAR.
Στις προδιαγραφές του προτύπου αναφέρεται ότι αναλόγως το δείγμα LAR πρέπει να κβαντίσουμε με διαφορετικό αριθμό bits (από 3 έως 6).
Ωστόσο στην MATLAB/Octave υποστηρίζονται ακέραιοι έως 8 bits (int8) (όχι λιγότερα).

Επομένως πρέπει εμείς να χρησιμοποιούμε ακεραίους 8bits όταν κβαντίζουμε τα LAR για να έχουν π.χ. τιμές από -3 έως 4, αλλά όταν αποθηκεύουμε στο αρχείο να βρούμε manually τα bits που χρειάζονται π.χ. 3 bits μόνο (για τιμές από -4 έως 3);

Ελπίζω να είναι κατανοητή η ερώτηση.

Αν και όντως με μπέρδεψες λίγο, πιστεύω ότι δε χρειάζεται να λάβεις υπόψιν κάτι τέτοιο. Δηλαδή, εσύ θα κβαντίσεις τα LAR, το αποτέλεσμα είτε είναι σε int8, int16, ή int32 (στα πλαίσια της εργασίας), τον ίδιο αριθμό θα αντιπροσωπεύει (αρκεί αυτός αριθμός να είναι σε διάστημα που μπορεί να αναπαρασταθεί απο το μικρότερο αριθμό bits). Στον αποκβαντισμό πάλι δε σε ενδιαφέρει το format του input. Επίσης τα LARc δε χρειάζεται να αποθηκευτούν, εκτός αν με το "αρχείο" εννοείς το αποκωδικοποιημένο σήμα, που επίσης δε χρειάζεται να το αποθηκεύσεις.

Επομένως θεωρούμε ότι τα κβαντισμένα LAR θα βρίσκονται εντός του διαστήματος [LARc_min, LARc_max] που περιγράφεται για κάθε δείγμα LAR στον πίνακα 3.1 του προτύπου;

Θεωρητικά ναι

Όσον αφορά το level 2 η ακολουθία d(n) προκύπτει εφαρμόζοντας τη διαδικασία του level1 σε όλο το s0; Ή θέλει κάτι διαφορετικό;
Μπορεί να έχω καταλάβει λάθος την εκφώνηση.

Ποιά πρέπει να είναι η δομή των αρχείων της εργασίας; Γιατί στην εκφώνηση δεν αναφέρονται λεπτομέρειες π.χ. πως θα ονομαστούν τα script επίδειξης.

Θα μπορούσατε να τα ονομάσετε demo1.m, demo2.m ..., ή level1.m, level2.m. Τα οποία είναι scripts τύπου "main" που τρέχουν τα αντίστοιχα παραδοτέα της εργασίας (χωρίς κανένα όρισμα).

Άρα συναρτήσεις + demos + 1 αναφορά report.pdf όλα μαζί σε ένα αρχείο AEM.zip

Για κάθε level θέλετε ξεχωριστή αναφορά ή README αρχείο;

Ρωτάω γιατί θυμάμαι Γραφική - ΨΕΕ ήταν συγκεκριμένη η δομή που έπρεπε να έχουμε.

Πολύ σωστά, μόνο που θα ήταν προτιμότερο να μπουν όλα σε ένα .zip αρχείο, χωρίς υποφάκελο.

Όπως κρίνετε εσείς ότι χρειάζεται ανάλογα με το πως έχετε δομίσει τον κωδικά σας.

Τα Nc και bc που επιστρέφει η RPE_frame_SLT_coder είναι για όλα τα subframe ή μόνο του τελευταίου subframe;

Εξαρτάται από τη δομή του κώδικά σας. Δηλαδή από το αν η κωδικοποίηση και η αποκωδικοποίηση γίνεται per frame, ή συνολικά για όλο το σήμα που έχετε στη διαθεσή σας.

Διόρθωση: Εννοούσα όλα τα subframe του τρέχοντος frame, αφού στις συναρτήσεις λέτε ότι στις εισόδους/εξόδους έχουμε ακολουθίες 160 δειγμάτων (άρα ένα frame).

Απλώς έχω μπερδευτεί λίγο στην αποκωδικοποίηση - τα Nc και bc που παίρνουμε λογικά είναι 4 ζεύγη ένα για κάθε subframe, σωστά;
Ώστε μετά να υπολογίσουμε το κάθε subframe και συνολικά να πάρουμε την ακολουθία d'(n) από την οποία με χρήση του FIR φίλτρου θα βρούμε το decoded frame s0.

Επίσης δεν έχω καταλάβει γιατί πρέπει η RPE_frame_SLT_decoder να επιστρέφει και το CurrFrmSTResd, αφού όλα τα CurrFrmSTResd τα έχουμε υπολογίσει στη διαδικασία του encode και άρα είναι ήδη διαθέσιμα.

Ενημερώθηκα για ένα τυπογραφικό λάθος στην εκφώνηση της εργασίας.

Συγκεκριμένα στην ενότητα "2.1.4 Compose Frame" αναφέρεται ότι:
"Το πλήθος και η διάταξη των bits ανα παράμετρο φαίνεται στο Table 6.1b της σελίδας 47 του προτύπου",

το οποίο δεν ισχύει. Αυτή η πληροφορία βρίσκεται στην "αρχή" του προτύπου και συγκεκριμένα στους πίνακες 1.2a και 1.2b (σελ. 12 - 13)

Επομένως το binary block θα είναι b6,b53,b109,...,b27 και όχι b1,b2,...b260, σωστά;

Σε τι εξυπηρετεί αυτή η αλλαγή στα bits;

Το binary block θα είναι b0, b1, b2, ..., απλά δε μπαίνουν με σειρά που βγάζει νόημα, αν ρωτάς αυτό

ξαναδιορθώνω, οι σωστοί πίνακες οι 1.1a και 1.1b

Όταν λέτε μπαίνουν με τη σειρά εννοείτε την σειρά δημιουργίας του binary block;
Βασικά έχω μπερδευτεί λίγο με το εννοεί το πρότυπο όταν λέει subjective importance of bits στους πίνακες 1.2a και 1.2b.

Έχω κάποιο πρόβλημα με το level 2. Ενώ στο level 1 το decoded ακούγεται πολύ καλά σε σχέση με το αρχικό, στο level 2 ακούγεται πολύ χάλια.
Η λογική μου στο level 2 είναι η εξής:
 - Σε επίπεδο encode/decode καλώ τις αντίστοιχες συναρτήσεις ως εξής (τα y και y_dec αφορούν σε 160 samples κάθε φορά):
for (...)
    [LARc, Nc, bc, CurrFrmExFull, CurrFrmSTResd] = RPE_frame_SLT_coder(y(...), PrevFrmSTResd);
    PrevFrmSTResd = CurrFrmSTResd;
    [y_dec(...), CurrFrmSTResd] = RPE_frame_SLT_decoder(LARc, Nc, bc, CurrFrmExFull, PrevFrmSTResd);
end

- Στον encoder ακολουθώ τα εξής βήματα (συνοπτικά):

• Pre-processing του σήματος s0.
• Εύρεση των συντελεστών LARc και της ακολουθίας d(n).
• Για κάθε subframe δημιουργώ την ακολουθία d'(n) με τα προηγούμενα 3 subframes (αναλόγως το τρέχων subframe παίρνω τα αντίστοιχα δείγματα από το προηγούμενο/τρέχων frame).
• Έπειτα βρίσκω τους συντελεστές N και b για το τρέχων subframe και τους κβαντίζω.
• Υπολογίζω την διαφορά e = d(n) - bc*d'(n-Nc) και την αποθηκεύω στο CurrFrmExFull.
• Τέλος, υπολογίζω το τρέχων subframe ως CurrFrmSTResd(...) = e + bq*d'(n-Nc), όπως ζητείται στην εκφώνηση.

- Στον decoder ακολουθώ τα εξής βήματα (συνοπτικά):

• Για κάθε subframe κατασκευάζω την ακολουθία d'(n) με τα τρία προηγούμενα subframes, όπως και στον encoder.
• Υπολογίζω τα αποκβαντισμένα N' και b'.
• Υπολογίζω το τρέχων subframe ως CurrFrmSTResd(...) = e + b'*d'(n-N'), όπου e είναι το αντίστοιχο (με το τρέχων subframe) τμήμα της ακολουθίας διέγερσης CurrFrmExFull.
• Στη συνέχεια ακολουθώ τη διαδικασία του decoder του level 1, δηλαδή εύρεση των συντελεστών a από τα LARc, υπολογισμός του s'(n) εφαρμόζοντας το κατάλληλο φίλτρο στην CurrFrmSTResd και τέλος εφαρμογή του post proccessing.

Δεν ξέρω τι μπορεί να πάει λάθος και να βγαίνει τόσο χάλια η ποιότητα του ήχου.

Ένα άλλο ερώτημα που έχω όσον αφορά το level 1 είναι ότι το decoded ηχητικό ακούγεται σχεδόν ίδιο με το αρχικό και η διαφορά τους είναι της τάξης 10^(-3).
Είναι φυσιολογικό αυτό; (Έχω στείλει τα ηχητικά στα συνημμένα).

Επίσης στο level 2 αναμένουμε να έχουμε καλύτερη/χειρότερη ποιότητα σε σχέση με το level 1;

Καλησπέρα, συγγνώμη για την καθυστέρηση (βέβαια, το νόημα του φόρουμε είναι η συζήτηση μεταξύ των συναδέλφων που υλοποιούν την εργασια). Σε πρώτη φάση τη 2η γραμμή μέσα στη for θα την έβαζα τελευταία.

Γενικά είναι λογικό το σήμα να είναι καθαρό στο level 1, εφόσον δεν έχει υποστεί "βαριά" επεξεργασια. Στο level 2 (και 3) είναι επίσης λογικό να υπάρχει κάποιο θόρυβος (λόγω παραδοχών της εργασίας αλλά και επειδή εκ των πραγμάτων, ο αλγόριθμος είναι lossy) (επίσης λόγω της μεγαλύτερης πολυπλοκότητας του level 2, είναι πιο εύκολο να γίνει κάποιο λάθος που μπορεί να παράγει ενθόρυβο σήμα, αλλά να μην καταλαβαίνεις αν υπάρχει λάθος ή όχι).

Η αλήθεια είναι ότι το δοκίμασα και δεν έβγαλα κάτι καλύτερο - λογικό το βρίσκω αφού, αν δεν κάνω λάθος, η διαδικασία υπολογισμού του CurrFrmSTResd είναι ίδια και στις 2 συναρτήσεις.

Ναι δεν ξέρω τι μπορεί να πάει λάθος ακόμη το ψάχνω. Γενικά η λογική που ακολουθώ και έστειλα παραπάνω (αν είναι κατανοητή βέβαια) έχει κάποιο λάθος;

Δεν διακρίνω κάποιο χτυπητό λάθος.
Επίσης μπορείτε να κοιτάξετε κι εδώ (https://www.thmmy.gr/smf/index.php?topic=62255.0) μήπως βρείτε κάποιο πληροφορία γενικότερα

Η ημερομηνία υποβολής της εργασίας παρατείνεται για 4 μέρες, δηλαδή η τελική ημερομηνία υποβολής είναι Τρίτη 8 Μαρτίου.

Όσον αφορά τα διάφορα επίπεδα προφανώς μπορεί ένα επίπεδο να καλεί συναρτήσεις του προηγούμενου επιπέδου, π.χ. το level 2 να καλεί συναρτήσεις του level 1 για να μην βάζουμε όλον τον κώδικα του short term predictor και στις συναρτήσεις του level 2;

Ναι γίνετα. Γενικά το πως θα δομήσετε το codebase σας είναι στη δική σας ευχέρεια, αρκεί να υπάρχει ένα demo script για κάθε επίπεδο.

Ωραία. Επίσης στο script μπορούμε να βάλουμε κάποιο δικό μας αρχείο ήχου για επίδειξη ή θα δοκιμάσετε εσείς δικά σας αρχεία;

Δικό σας.

Το πρότυπο θεωρεί πως το format του σήματος εισόδου στον κωδικοποιητή είναι 13 bit uniform PCM. Έχω καταγράψει κάποια ηχητικά και προσπαθώ να το φορτώσω με την audioread αλλά τα bits per sample που επιτρέπει 8,16,24,32 και 64. Εσείς πως έχετε φορτώσει τα ηχητικά; Αντιμετωπίσατε το ίδιο πρόβλημα;

Δε χρειάζεται να αναπαραστήσεις το σήμα σου με 13bit

Μετά από αρκετές δοκιμές, στο επίπεδο 2 εμείς παίρνουμε το ίδιο ακριβώς σήμα με το σήμα εισόδου στο επίπεδο 2 (δηλαδή το ίδιο σήμα με την ΄έξοδο του επιπέδου 1. Αυτό θεωρούμε ότι είναι σωστό, εφόσον οι προβλέψεις γίνονται με τα ίδια ακριβώς b και N που είναι γνωστά στον decoder και τα σφάλματα της πρόβλεψης e δεν έχουν υποστεί κβαντισμό. Χάνουμε κάτι στο σκεπτικό; Άλλωστε από την έκφωνηση αναφέρεται ότι στην μεταβλητή CurrFrmExFull έχουμε τα σφάλματα χωρίς κβαντισμό και χωρίς κωδικοποίηση, επομένως δεν μπορούμε να βρούμε κάποιο σημείο στο οποίο να χάνεται πληροφορία.

Λίγο με μπερδεύει αυτό. Εννοείς ότι το σήμα εξόδου του επιπέδου 2 (e[n] ή d'[n]; ) είναι ίδιο με το σήμα εισόδου του επιπέδου 2 (s0;);

Δεν το διατύπωσα σωστά, εννοώ ότι δεν έχουμε καθόλου loss γενικά στο επίπεδο 2 και ό.τι loss υπάρχει οφείλεται στο loss του 1ου επιπέδου. Αυτό, θεωρούμε ότι οφείλεται στο ότι το
 CurrFrmSTResd μπορεί να ανακτασκευαστεί πλήρως, εφόσον ο decoder έχει και τα CurrFrmExFull και τα b,N για κανει την πρόβλεψη. Η long term πρόβλεψη δημιουργεί loss αλλά αυτό φαίνεται στο 3ο παραδοτέο λόγω κβαντισμού των errors και υποδειγματοληψίας.

Πολύ ωραίο σκεπτικό

Νομίζω θα συμφωνήσω σε αυτό που λες καθώς τόσο o encoder όσο και decoder χρησιμοποιούν κβαντισμένες εκδοχές των N και b.
Ωστόσο εγώ έχω απώλειες στο level 2 καθώς ο ήχος έχει αρκετό θόρυβο. Στο level 1 δεν έχω απώλειες (η διαφορά των σημάτων είναι της τάξης του 10^(-3)).

Πως δημιουργείται αυτό ο θόρυβος; Κάνεις κάποιον κβαντισμό; Ή κάποιο estimation?

Ο μόνος κβαντισμός που κάνω είναι στα N και b που τα ίδια χρησιμοποιούν οι encoder και decoder στην σύνθεση.

Τελικά και στο δικό μου level 2 δεν έχω πλέον θόρυβο - το λάθος που είχα είναι ότι έκανα 2 φορές τη διαδικασία του preprocessing (1 στην αρχή του level 2 coder και 1 γίνεται ήδη στον level 1 coder που καλεί ο level 2 coder εσωτερικά).
Επίσης στο level 3 παράγω σήμα με κάποιον θόρυβο ο οποίος δεν ξέρω αν είναι ανεκτός στα πλαίσια της εργασίας.

@perukas γενικά πόσο μπορεί να επηρεάζει τη βαθμολογία της εργασίας η ποιότητα του decoded ήχου;

Στη βαθμολόγηση της εργασίας λαμβάνεται υπόψιν η ορθότητα του αλγορίθμου. Η "πολύ κακή" ποιότητα του αποτελέσματος, λογικά  από κάποιο λάθος προκύπτει