Recensubs HQ

Posts written by Liquid Dr4k3

view post Posted: 24/2/2015, 00:21     +1[DOMANDA] Deinterlacciare e rendere progressivo un BD - Il ghetto dei fansubbers
È telecinato a pattern variabile. Non so cosa utilizzi solitamente per fare IVTC, ma se usi qualche automagicivtc tipo tfm.tdecimate, e con questi non ottieni un buon risultato, ti restano 2 strade:
1) Ci diventi pazzo con YATTA: miglior risultato, ma circa 2-3 ore ad episodio solo per l'ivtc (i->Ctrl+s->i->Ctrl+s-> ecc ecc)
2) Bobbi tutto con qualcosa tipo QTGMC e gg.
view post Posted: 23/2/2015, 17:02     [DOMANDA] Deinterlacciare e rendere progressivo un BD - Il ghetto dei fansubbers
Servirebbe un breve sample per capire cosa hanno combinato. I DVD NTSC sono sempre telecinati, male che ti può andare a pattern variabile, mentre invece sui BD interlacciati c'è quasi sempre l'easter egg. BTW, se è roba QTec stuprata ti consiglio di buttare il BD e usare il DVD se reperibile.
view post Posted: 3/2/2015, 09:32     +1"Out of memory"... per un video della durata di una opening? - Il ghetto dei fansubbers
Più che altro tutti i filtri di aa internamente interpolano con qualcosa di più o meno furbo per eliminare le discontinuità, poi downscalano con qualcosa alla risoluzione della clip in ingresso. Quindi quei frame su cui stai facendo aa si beccano nell'ordine: 1080p -> dbl a 720p -> interpolazione con eedi3 (720x2) -> spline a 720p (mi sembra che ediaa3 usasse quello per downscalare) -> bilinear (?) a 1080p

Se poi li sharpi pure quei poveri frame chiedono pietà. In generale, se si ha qualcosa 1080p che va downscalato, preferisco mettere l'aa dopo il resize che interpola sulla clip a 1080p e poi downscala direttamente alla risoluzione finale. Così:

1) ti eviti troppi downscale/upscale che indolore non sono
2) in generale ho visto che interpolando a 1080p le discontinuità vengono eliminate in maniera più efficiente dal filtro di interpolazione. Facendo kernel inversion su qualcosa di aliasato si ottiene un qualcosa di ancora più aliasato, il che in teoria dovrebbe rendere più facile al filtro di interpolazione l'identificazione di queste discontinuità. Ma ho notato che spesso il risultato è l'opposto, cioè che non vengono toccate a meno di non usare rfactor 9001 (già a 4 su una clip 1080p mi va out of memory con 6Gb di ram). Oltretutto usando rfactor superiore al 2 ho notato che spesso se si hanno dettagli parecchio fini eedi3 li va a "mescolare" facendo un casino.

Quindi, imho, se hai un qualcosa che non devi resizzare usa il filtro proposto da hell (magari senza rpow2 visto che sp me lo aveva criticato, quindi usando eedi3 con dh=true e fturnright/left), se invece devi resizzare meglio che inserisci qualcosa te a mano dopo il resize che prenda la clip a 1080p, la interpoli e poi la downscali alla risoluzione finale. Chiaramente visto che interpoli su 1080p invece che 720p i tuoi fps subiranno una bella botta, ma penso ne valga la pena.

Edited by Liquid Dr4k3 - 3/2/2015, 13:52
view post Posted: 2/2/2015, 20:48     +5Richieste recensub - Recensubs
CITAZIONE (mirkosp @ 2/2/2015, 20:46) 
CITAZIONE (rufy94 @ 2/2/2015, 20:00) 
@H e l l. Hai ragione, ma Nizuma ha insistito molto per imitare SP xD beh almeno ora ho capito perché SP usa il 4:4:4... io avrei tranquillamente muxato da una 10p
@Mirkosp Ora diciamo di aver capito perché usi il 4:4:4, per quanto riguarda l'opus? Voglio dire è buono ma secondo me è meglio l'AAC.
Tranquillo che non commetterò più lo stesso errore :P appena posso farò una v2 (si lo so, per un film così lungo fa ridere) prometto che farò una degna imitazione del tuo encode xD

A bitrate sufficientemente alti aac e opus si equivalgono, a bitrate bassi opus dà merda ad aac.

Hydrogenaudio aveva fatto un test a 96kbps indicativi (i risultati li trovi qui), con bitrate effettivi che hanno di poco superato i 100kbps e in cui opus è risultato il codec migliore, superando anche AppleAAC, che era l'encoder migliore e che utilzzavo prima dell'avvento di opus.
Per le release, encodo con un target indicativo di 128kbps; a quel bitrate ovviamente la differenza (comunque non eccessiva neanche a 96kbps) tra AppleAAC e Opus si assottiglia sempre di più, ma Opus comunque mantiene un piccolo margine qualitativo rispetto ad AAC, quindi consente un leggero guadagno.

TL;DR per 10 mega di filesize in meno ti ritrovi connor tra i coglioni.
view post Posted: 7/1/2015, 15:42     +1T'amo, pio utonto! - Tutto il resto...
Ha ragione il comma abuser, Cusy è pagato dai dev di CCCP per usare e sponsorizzare OPUS.
Vogliamo delle spiegazioni.
view post Posted: 28/10/2014, 19:45     OPF + TAFF: Nuova recensub? - Il salotto del fansub
Cabraman ti prego, resizzalo. Il mio monitor non riesce a contenere la potenza di quello screen fullaccadì
view post Posted: 28/10/2014, 19:23     +18OPF + TAFF: Nuova recensub? - Il salotto del fansub
CITAZIONE (Ars_Nova @ 28/10/2014, 19:17) 
Sto scaricando la prima di Xam'd, prepare your self.

ulccWpGl

finalmente un parere autorevole!
view post Posted: 10/10/2014, 15:46     +23Esistono gemellaggi che non esistono - Il salotto del fansub
cR2syMg

Signori, siamo dinanzi ad una svolta epica per il mondo del fansub
view post Posted: 3/10/2014, 17:14     +1Inverse Kernel Resize and you - Guida galattica per fansubbisti
Magari a qualcuno può servire quindi la butto qua. In un paio di occasioni mi è servito di maskare dei credit, ma per vari motivi usando il mask proposto da chibi mi si andava ad aggiungere alla mask roba che non volevo. Questo non per colpa della mask chiaramente, ma magari perché stavo andando ad usare dbl a 720p su un qualcosa che 720p non era (senza che dbl facesse troppi danni), come mi è capitato di recente con una .ts di ZnT. Per evitare questo sono andato a modificare leggermente la funzione proposta da chibi aggiungendo un'ulteriore modalità, la quale va a creare la mask su un principio completamente diverso dal fare la differenza tra la clip di partenza e la clip downscalata con dbl e riupscalata con bilinear. Per la precisione questa modalità sfrutta il fatto che, solitamente, i credit sono aggiunti in pc-range, mentre tutto il resto DOVREBBE essere in tv-range. Quindi, andando a fare la mask su tutto quello che ha il luma in pc-range, si dovrebbe ottenere qualcosa di più o meno accurato. Veramente, l'ho modificata al volo e usata un paio di volte a dir tanto, quindi se notate qualcosa che non va fatemi sapere. Più che altro vuole essere uno spunto.

CODICE
function MaskDetailMod(clip clp, int final_width, int final_height, int "RGmode", int "cutoff", float "gain", int "expandN", int "inflateN", bool "blur_more", float "src_left", float "src_top", float "src_width", float "src_height", int "Mode", int "thr")
{
Mode = default( Mode,  1 ) # =1 -> mt_makediff   !=1 -> PC-Range Mask
thr = default( thr,  233 )
RGmode = default( RGmode,  3)  # spatial filter to remove false positive (noise, compression artifact and so on) , this is its mode
cutoff = default( cutoff,  70 ) # exclude from the mask the pixel with less than this value
gain = default( gain,  0.75 ) # increase the value of the remaining pixel
expandN = default( expandN,  Mode==1 ? 2 : 4 ) # how many mt_expand
inflateN = default( inflateN,  Mode==1 ? 2 : 4 ) #how many mt_inflate
blur_more = default( blur_more,  false ) #additional blur after resize
src_left= default( src_left,  0 )
src_top = default( src_top,  0 )
src_width = default( src_width,  0 )
src_height = default( src_height,  0 )
CUT   = string(cutoff)
GAN = string(gain)
TH = string(thr)

initial_mask= Mode==1 ?
\ mt_makediff(clp,clp.debilinearY(final_width,final_height).bilinearresize(clp.width(),clp.height()),u=1,v=1).Removegrain(RGmode,-1) :
\ mt_lut(clp, "x "+TH+" > x 0 ?",u=1,v=1).Removegrain(RGmode,-1)

mask = initial_mask.histogram("luma").mt_lut("x "+CUT+" < 0 x "+GAN+" 256 x + 256 / * * ?",u=1,v=1)
expanded = mask.expandMask(expandN)
inflated = expanded.inflateMask(inflateN)
final = blur_more ? inflated.BilinearResize(final_width, final_height, src_left, src_top, src_width, src_height).Removegrain(12,-1) : inflated.BilinearResize(final_width, final_height, src_left, src_top, src_width, src_height)
return final.Greyscale()
}

function expandMask(clip clp, int "expandN")
{
return expandN > 0 ? expandMask(clp.mt_expand(u=1,v=1), expandN - 1) : clp
}

function inflateMask(clip clp, int "inflateN")
{
return inflateN > 0 ? inflateMask(clp.mt_inflate(u=1,v=1), inflateN - 1) : clp
}


È uguale a quella nel primo post, semplicemente ho aggiunto mode e thr. Mettendo Mode a 2 (o qualunque cosa diversa da 1 che è il valore di default) si va a creare la mask considerando il pc-range. Invece thr determina il valore di soglia oltre il quale si va a maskare. In teoria thr dovrebbe essere 235, ma ho notato che spesso conviene metterla un poco più bassa per prendere meglio quello che ci interessa, tanto se viene preso qualcos'altro spesso questo viene filtrato da degrain e lut successivi. Quindi di default l'ho messa a 233, ma se si vuole si può modificare mentre si fa un riscontro visivo su quello che stiamo maskando. Inoltre ho notato che maskando sulla base del pc-range spesso conviene dare qualche ciclo in più di inflateMask e expandMask, visto che con 2 cicli solitamente ci si perde qualcosa. Di conseguenza, se si utilizza un Mode != 1, i cicli di inflateMask e expandMask di default saranno 4 invece che 2.
view post Posted: 14/9/2014, 14:01     +3Il topic degli screen random - Fun & Fail
CITAZIONE (Mad_Hatter™ @ 14/9/2014, 13:56) 
CITAZIONE (hyoudo issei @ 14/9/2014, 13:42) 
La frase cambia dal tema della situazione, adesso non mi ricordo bene in che contesto era riferita quella frase, ma avevo deciso di lasciarla così, perché il tono con qui lo diceva sembrava abbastanza euforico, ma va beh, cercherò di star più attento d'ora in poi ^^

Anch'io quando sono euforico succhio la faccia delle persone. Ma vai a cagare va.

Awy9zD4

Dicevi?
view post Posted: 21/8/2014, 18:06     +1BD originali vs BDrip pirata - Il salotto del fansub
Tranquillo, sp probabilmente avrà un attacco di cuore alla 4° riga
view post Posted: 21/8/2014, 17:55     +2Richieste recensub - Recensubs
CITAZIONE (Jonky @ 21/8/2014, 18:39) 
Qualcuno sarebbe disposto a fare una recensub di Mahouka Koukou no Rettousei versione PD-Fansub (dove PD sta per "pulcini dolci" e non "partito democratico")?
Chissà, magari sono validi :D

Noto con piacere che prima di chiedere hai controllato scrupolosamente la sezione recensubs
view post Posted: 19/8/2014, 18:23     Richieste su encoding da parte di un niubbo? - Il ghetto dei fansubbers
CITAZIONE (tasver @ 19/8/2014, 16:35) 
No, non ho fretta, è che troverei futile adoperare una metodologia di scaling in questo caso che mi dia qualità molto simile e tempo di elaborazione maggiore... non riesco proprio ad accettarlo neanche nell'encoding.

In linea generale personalmente utilizzo già più istanze di handbrake ad esempio, per utilizzare tutti i miei 4 core fisici, alla fine esiste sempre la soluzione che offre più fps elaborati e quindi minor tempo di elaborazione una volta trovata quella, se la qualità non è come quella risultante per esempio dall'encoding hardware del quicksynch (visto ieri un risultato, non accettabile).

Alla fine però sono solo un novizio, devo ancora imparare e farò tutti i test necessari ^^

Non so handbrake visto che non l'ho mai aperto, ma x264 è multithreading eh... non è che ne devi lanciare 9001 istanze per cappare la CPU (e quasi sicuramente lo stesso vale per handbrake, visto che suppongo vada a richiamare x264). Solitamente con una sola istanza mi ritrovo 8 core (4 fisici e 4 logici) al 100% e 2-3 fps. Poi per roba con script particolarmente complessi posso anche ritrovarmi la cpu al 10% con 1fps, ma quello è un discorso a parte.
Also, ti prego... mi fai sentire in colpa se usi PointResize. Fidati di sp quando diceva che stavo trollando. Vatti a leggere come funziona (anche se già leggendo nearest neighbor dovresti capirlo) e vedrai che non ti verrà più in mente di usarlo. Fare a pezzi un video per guadagnare un'inezia in termini di fps è un'assurdità, e anche uno che sta agli inizi dovrebbe capirlo.
view post Posted: 19/8/2014, 11:51     Richieste su encoding da parte di un niubbo? - Il ghetto dei fansubbers
CITAZIONE (mirkosp @ 19/8/2014, 12:05) 
Dunque... PointResize è LAMMERDA, e Drake stava trollando in quel post. Per fare resize come si deve dovresti imparare a usare debilinear, debicubic e invks, ma sono cose avanzate che richiedono ragionamenti ed eventualmente anche mask e filtraggio scena per scena. Per un novellino è meglio utilizzare resamplehq e controllare semplicemente quale kernel conviene utilizzare con la determinata sorgente.

Riguardo alla questione 60fps, le altre risposte denotavano una certa ignoranza dovuta a eccessiva fortuna, immagino: Bas aveva per mano un 60i full field blended, per cui l'unico modo per massimizzare la fluidità minimizzando la visibilità del blending in playback era mantenere tutti i field. Quindi, per rendere progressivo, ha dovuto bobbare, perché droppando field o blendandoli assieme si sarebbe ritrovato un video più fastidioso da guardare in playback, indipendentemente da questioni di pattern, visto che sarebbe stato più visibile il blend in playback.

Più che eccessiva fortuna mia direi eccessiva sfiga tua, una porcata del genere (ringraziando il cielo) non capita quasi mai.
view post Posted: 19/8/2014, 08:00     Richieste su encoding da parte di un niubbo? - Il ghetto dei fansubbers
CITAZIONE (Vaz @ 19/8/2014, 07:32) 
Fermi tutti, da dove esce fuori PointResize? Che differenza c'è con ResampleHQ?

No no, lascialo dove sta... sarebbe nearest neighbor, cioè l'algoritmo di resize più "basilare". Sicuramente ti "trasforma un 1080p in un 720p!!1!1!", ma il suo utilizzo è caldamente sconsigliato.
197 replies since 18/7/2011