morrolinux / simple-ehm

A simple tool for a simple task: remove filler sounds ("ehm") from pre-recorded speeches. AI powered.
MIT License
228 stars 19 forks source link

Aggiunto argomento "name" #13

Closed Guray00 closed 3 years ago

Guray00 commented 3 years ago

Ho aggiunto l'argomento --name in modo da poter decidere in quale modo denominare il file di output, ovvero la stringa che verrà concatenata in output. Esempio:

python3 ./simple_ehm-runnable.py video.mp4 --name "[CUT]"

realizzerà un nuovo file denominato video[CUT].mp4

Complimenti per il tuo lavoro e per i tuoi video, grandissimo!

morrolinux commented 3 years ago

Ciao! Grazie per il tuo contributo. Ti lascio due appunti come review per chiederti un paio di chiarimenti, fose sarebbe comodo modificare un paio di cose per migliorare la manutenibilità del codice nel lungo termine :)

Guray00 commented 3 years ago

Ciao! va benissimo, sto facendo altre modifiche minori cercando di sporcare meno codice possibile.

In particolare ho notato che la metodologia di taglio che eseguivi non era accurata e generava errori in alcuni file, non so specificare quali (ma c'è un issue già aperta al momento nella quale ho già scritto). Ho modificato facendo quello che è denominato fast and accurate seeking impostando il parametro -ss sia prima che dopo -i. Maggiori dettagli qua: https://superuser.com/questions/138331/using-ffmpeg-to-cut-up-video

Un'altra modifica che sto attuando è l'aggiunta del parametro --keep-junk in modo che alla chiusura forzata o automatica del programma tutti i file temporanei vengano cancellati, mentre verranno mantenuti se tali opzioni sono fornite. Per qualsiasi chiarimento sono disponibile, credo molto in questo progetto e in questi due giorni sto studiando la repo per cercare di essere utile

Guray00 commented 3 years ago

Ottimo! Ricorda di fare una PR separata per ogni funzionalità distinta

Hai ragione, mea culpa non ho troppa esperienza su github e non avevo intenzione di fare così tante modifiche distinte. Cerco di non toccare più il codice e aprire pr diverse, perdona l'ignoranza. Commento subito i codici

Guray00 commented 3 years ago

Comprendo di aver generato qualche disagio in tal senso, ma sarebbe possibile valutare il codice senza dover rigenerare più pr per queste modifiche? Non sto riuscendo a crearne senza eliminare questa, magari evito di rimettere mano sul codice per aggiungere funzionalità fino a quando queste non saranno approvate (o respinte).

morrolinux commented 3 years ago

Comprendo di aver generato qualche disagio in tal senso, ma sarebbe possibile valutare il codice senza dover rigenerare più pr per queste modifiche? Non sto riuscendo a crearne senza eliminare questa, magari evito di rimettere mano sul codice per aggiungere funzionalità fino a quando queste non saranno approvate (o respinte).

Non ti preoccupare! Git per certe cose è un po' ostico e manda in disperazione. Sto pensando a come farti fare una PR pulita senza impazzire con i comandi di git.. Il migliore compromesso probabilmente è questo:

  1. Fai una copa di backup dell'intera cartella contenente il tuo repo clonato
  2. Apri una shell nella cartella del repo e torna indietro fino al commit che conteneva solo le modifiche inerenti git revert f4eec75e670690dd5d503ea5265e89b4b5e3db42 - PS: puoi trovare tutti gli hash dei commit scrivendo git log e leggendo la history.
  3. A questo punto sarai tornato alle modifiche di ieri. Puoi controllare con il tuo IDE se il codice è corretto. scrivi git push
  4. Per pulire la history degli ultimi commit in eccesso, incluso il commit di revert (dovrai contare su git log quanti sono, credo saranno 4) scrivi git reset --soft HEAD~4
  5. Ora puoi eseguire un nuovo commit come se nulla fosse mai successo: git commit -m "messaggio di commit"
  6. E avendo modificato la history localmente probabilmente dovrai pushare con l'opzione --force: git push --force

Tanto prima o poi dovrai imparare. Almeno io non sono un tuo superiore ;)

morrolinux commented 3 years ago

Naturalmente le modifiche successive non collegate a questo commit le puoi andare a recuperare dalla cartella di backup che hai fatto al punto 1.

Guray00 commented 3 years ago

Perfetto, grazie mille per il tuo supporto vedo di sistemare tutto al più presto. In ogni caso mi prendo qualche giorno giusto per fare le pr tutte insieme e non costringerti a leggere le modifiche volta volta. Ciascuna funzionalità quindi avrà bisogno di un clone a parte su cui apportare le modifiche? (sennò penso risucceda come ora, che ad ogni modifica la pr si aggiorna)

morrolinux commented 3 years ago

Dovresti creare un nuovo branch per ogni feature che sviluppi: git checkout -b nome_feature così non avrai il problema della PR che si aggiorna quando non vuoi

Guray00 commented 3 years ago

Mi sto occupando di fare come richiesto delle nuove pr per ciascuna funzionalità.