Newsgroup: it.comp.musica.mp3
Titolo: Mp3, file-sharing e resume

In una precedente discussione sul resume automatico dei programmi di
file-sharing si era detto che due MP3 pur avendo stesso nome del file,
stesso bitrate, stessa dimensione in byte e pur essendo uguali un certo
numero di byte nell'intorno del punto di resume, tali file possono non
essere perfettamente uguali.
Ne deduco che nella decodifica MP3 ci siano punti in cui vengono inseriti
blocchi di dati di grandezza in byte definita (altrimenti si avrebbero files
di lunghezza diversa) che possono variare a livello di contenuto da file a
file. Che tipo di informazioni memorizzanno? Questi blocchi hanno posizioni
definite? L'unico modo per vedere se due files MP3 sono identici è quello di
controntarli byte a byte dall'inizio alla fine? Dove posso trovare
informazioni sull'argomento?
Grazie a chi mi sarà d'aiuto!
Ciao a tutti.

 file.
Molto perspicace. In effetti č proprio cosě: quei blocchi vengono chiamati
"frame", e per gli mpeg layer I contengono 384 sample audio, mentre per i
layer II e III sono 1152. La dimensione dei frame č data da
   FrameSize = 144 * BitRate / SampleRate + Padding
solo per i layer II e III. Un mp3 CBR a 128, 44100 Hz, č composto da frame
lunghi 417 byes.
MaxArt

 che il file sia lo stesso.
Quando si tratta di file lossy, la verifica binaria (sul modello fc /b) 
garantisce SOLO quando viene eseguita dall'inizio alla fine del file (o 
dall'inizio alla fine del segmento che si e' gia' scaricato), altrimenti 
la sicurezza al 100% non si ottiene.
Cia', mumble

 la sicurezza al 100% non si ottiene.
Infatti non ho parlato di certezza.
Ma il tuo discorso è valido anche quando non si parla di file lossy, ma in
genere per qualsiasi file. Perché hai tirato in ballo le compressioni lossy?
MaxArt

 Perché hai tirato in ballo le compressioni lossy?
Per motivi che ho gia' spiegato piu' volte (ripreso un po' anche sopra).
Ma comunque, ripetendo un po' la solfa,
quando con un TIPICO programma di sharing si scarica da utenti diversi un 
brano lossy che NOI pensiamo sia lo stesso (stesso nome, stessa durata-
bitrate, stesso encoder, e magari anche stessi tag, che potrebbero 
benissimo non esser presenti, come succede in molti mp3 o, se presenti, 
potrebbero essersi serviti dello stesso database, come spesso accade, 
quindi medesime entry ID3) non c'e' alcuna certezza che lo sia al 100% 
(visto che, come gia' dimostrato in precedenti post, ci sono impostazioni 
di encoder che agiscono sulla qualita' finale, ma che non 
influiscono minimamente sulla dimensione finale del file).
Naturalmente queste considerazioni valgono in primis per quei programmi 
(morpheus e audiogalaxy) che adottano in maniera spudoratamente 
superficiale una "filosofia" di resume che puo' solo recar danni, in 
AGGIUNTA a quelli che POTREBBERO esser gia' presenti nel file di 
partenza.
Si', le possibilita' di beccare questi casi sono rare, ma non quanto 
possa sembrare (infatti io sono a quota 6 con casi del genere), 
soprattutto tra "circoli" di persone che usano stesso encoder e stesso 
ripper, tipico il caso di Lame ed EAC (quindi una buona percentuale di 
eliminazione delle variabili encoder, impostazione qualitativa e id3tag), 
e magari applicati su brani famosi e quindi comuni (eliminazione 
variabile durata).
Quello che poi mi fa incazzare ancor di piu' e' che ho riscontrato (nel 
mio test con amici ai quali ho consegnato di persona degli mp3 
rarissimi che io ho codificato e che poi ho ri-scaricato da remoto, 
sempre da loro e a piu' riprese) resume non eseguiti a regola d'arte con 
morpheus e audiogalaxy, perfino scaricando da stesso utente.
Queste situazioni, che personalmente ritengo inaccettabili, non mi sono 
mai capitate con BuddyShare e WinMX (anche se ho letto che tu, max, hai 
avuto con quest'ultimo programma un problema del genere, cioe' un 
problema scaricando a piu' riprese da stesso utente).
Cia', mumble

 problema scaricando a piu' riprese da stesso utente).
Il mio caso si può dire molto raro. Il file in questione l'ho preso da due
utenti, ma uno dei due - ahimé - aveva fatto un pasticcio...
La colpa certamente non era di WinMX.
MaxArt

scaricato e sul file remoto da cui si vorrebbe "resumare"),
come chiedevo in un altro post, non sarebbe utile il CRC?
in questo modo verrebero aggiunti dei dati di controllo all'mp3 ma con
il vantaggio che si puo' sapere se e' stato danneggiato durante i
passaggi in rete.

 come chiedevo in un altro post, non sarebbe utile il CRC?
Sicuramente (cosi' fa ad esempio BuddyShare ed anche Filetopia, 
quest'ultimo e' tra quelli che mi sono piaciuti maggiormente nel post 
napster, ed e' anche efficiente, oltre a non dover sottostare a eventuali 
dictat USA, visto che il tutto ruota in Spagna), ma bisogna vedere come 
viene implementato questo benedetto controllo di ridondanza ciclico, 
visto che in passato ho incocciato il muso in protocolli Xmodem CRC 
tutt'altro che perfetti (certo, si parla di periodo bbs, reti a 
commutazione di circuito e di emulazione terminale).
Il controllo binario totale dall'inizio alla fine del file rimane 
naturalmente la strada piu' sicura, ma un CRC, partendo almeno sui 16 
bit, dovrebbe essere la strada migliore tra sicurezza e praticita'-
gestibilita'.
Comunque, come hai giustamente fatto notare, non mancano le possibilita', 
e' solo che sono feature-interventi non richiesti dai tipici scaricatori 
di porto e comunque questi discorsi si potevano anche lasciare da parte 
se solo due infami programmi non avessero introdotto un approccio di 
resume totalmente sbagliato alla base.
Tutto questo imho (e' meglio che lo metta altrimenti nun me lasciano 
respira').
Cia', mumble

napster,
Io il CRC pensavo pero' anche e sopratutto di applicarlo al momento di
encodare l'mp3. e' previsto nello standard mp3, poi non so' se sia
davvero efficente. cosi' se si scarica un mp3 incollato male l'errore
e' piu' evidente e si puo' non condividere (per educazione) o
riscaricare.

 riscaricare.
Penso che il CRC sia contrario alla filosofia del progetto MPEG...
Mia ipotesi...
MaxArt

 encodare l'mp3.
Cosi' facendo vengono sottratti bit alla codifica audio, non so quanto 
questo possa piu' o meno incidere sul risultato finale (onestamente non 
ho mai provato), ma so che quando si effettuano listening test e' 
decisamente consigliato un "no crc" nell'impostare la codifica dell'mp3.
Cia', mumble

 gestibilita'.
Riporto per conoscenza le caratteristiche del resume di Buddyshare:
- CRC 32
Quindi un controllo a 32 bit identico a quello di Winamp effettuato alla
fine del DL che elimina i file resumati male. E' seccante quando capita
(2 volte nella mia carriera) ma è altamente sicuro. In ogni caso il
perogramma lascia il file resumatlo male in una cartella nascosta del
programma per eventuali controlli da eseguire a manina.
- firma digitale di 48 Bytes all'interno del file
Controllata a livello preventivo prima di resumare il file.
- controllo binario e accavallamento del bordo del file (non ricordo di
quanti Byte)
- resume sempre dallo stesso utente
- resume automatizzato tipo audiogalaxy ma con una sicurezza nemmeno
paragonabile!
Per quanto ne so Filetopia implementa un sistema CRC ma credo a 16bit.
IN compenso abilita la crittazione dei file e delle ricerche durante il
download che in questo periodo di controlli potrebbe risultare molto
utile.
Ciao!
--
 ___                                   _         _
/ __| ___  _ _   ___ __ _  _ __  __ _ | |_  _ _ (_) __ _
\__ \/ -_)| ' \ |_ // _` || '_ \/ _` ||  _|| '_|| |/ _` |   Tutto su
|___/\___||_||_|/__|\__,_|| .__/\__,_| \__||_|  |_|\__,_|  MpegPlus e
 
senza...@yahoo.it
   |_|  
www.mpplus.3000.it
         Buddyshare!!

decisamente consigliato un "no crc" nell'impostare la codifica dell'mp3.
io so' che l'mp3 e' piu' grande, tu dici che vengono sottratti bit
audio, ne sei sicuro? in questo caso a morte il CRC

 utile.
Certo, a suo tempo ho usato molto Filetopia e sinceramente lo preferisco 
di gran lunga a Buddy (che ormai ho preso ad odiare), e questo per vari 
motivi, prevalentemente di programmazione.
Cia', mumble

, 
chic...@TOGLIQUESTOyifan.net says...


Ti ho gia' detto che non ho mai provato, ho solo riportato alcuni 
commenti di quelli che testano da tempo (ff123 incluso), a me il discorso 
non mi ha mai minimamente interessato (anche perche' sarebbe un 
accorgimento valido solo se facesse breccia in molti bozzi, ma cosi' non 
e' e non sara' mai).
Cmq oggi ho fatto una mia prima prova. Ho usato il plugin mp3 ME di 
CoolEditPro1.2a per encodare due mp3 (a 160kbps in cbr con joint stereo), 
uno con crc attivo e l'altro no, risultato: i due file hanno dimensione 
identica, dunque..........
Cia', mumble

 motivi, prevalentemente di programmazione.
E va beh... Buddyshare sarà pure fatto con il VBA ma non vedo come
questa scelta possa dare problemi insormontabili. A me non si impunta da
moltissimo tempo ormai e nelle ultime versioni è più che stabile. Forse
l'unico errore è stato rilasciare il programma in fase di alpha testing
cosa che ha allontanato molti utenti. Da quando invece sono uscite
versioni beta stabili, non ci sono molte difficoltà di utilizzo. Se poi
ti riferisci a qualche aspetto in particolare... fammi sapere!


Ciao!
Ciao!
abc

 lentezza era disarmante! Avrò pure un 56k, ma non superava MAI i 2kbps
Dipende da chi stai scaricando data la possibilità di limitare la banda
disponibile per i singoli DL. Io che scarico da gente con linee cable o
ADSL vado con tranquillità a 6KB al secondo con il mio modem interno da
30mila lire!
Ciao
