Newsgroup: it.comp.musica.mp3
Titolo: Archiviazione audio

Vorrei usare EAC per archiviare in formato .ape CD musicali ma vorrei
farlo in modo da garantirmi la massima flessibilità d'uso di questi
archivi.
Ovvero mantenere la possibilità di ascoltare i files archiviati su HD o
CD-ROM, di condividerli in rete se mai disponessi di banda sufficiente, di
convertirli in formato lossy come mpc, AAc o mp3, o di ricreare un CD
Audio a partire dai files .ape: tutto questo nel modo più efficiente e
rapido possibile.
Il fine è preparare una sorta di protocollo operativo che sia ottimizzato
per queste necessità.
Dal lato hardware dispongo di un ottimo Plextor PX-40TS che con l'offset
correction, la capacità di overread nel Lead-in/Lead-out, il test del CRC
mi garantisce estrazione perfetta dei dati audio. Per motivi di
conversione/condivisione preferisco estrarre la singole tracce invece che
un unico file .wav. Uso la extra high compression e salvo insieme ai file
..ape anche il file di log e il CUE Sheet. Purtroppo EAC mi consente solo
il tagging ID3v1 e inoltre il CUE Sheet deve essere modificato per
sostituire l'estensione .wav con quella .ape. Chiedo 2 cose: c'è ragione
di preferire l'APE tagging che sarebbe quello nativo sia per monkey'audio
che per musepack al tagging ID3v1 ? Inoltre avevo letto di problemi che
affliggevano monkey's audio (errori CRC in decodifica e non affidabilità
del "verify"): c'è modo di garantirsi una ragionevole integrità e
inalterabilità dei dati ?
Grazie a chi vorrà rispondermi,
cat.one

 ragionevole integrità e inalterabilità dei dati ?
Questo è un problema che c'era con le versioni precedenti... questi
problemi sembrano essere scomparsi con le ultime versioni.
Naturalmente evita sistemi overcloccati o comunque poco stabili.
Per quanto riguarda l'inalterabilità dei dati il consiglio che posso
darti oltre a quello ovvio di usare supporti di qualità è quello di
controllare il CD dopo la masterizzazione (tramite utility apposite) e
di incapsulare i files APE all'interno di archivi RAR nei quali hai
inserito dei dati ridondanti. Molti utilizzatori hanno richiesto
l'implementazione di un metodo di correzione degli errori direttamente
nei files APE ma per ora Matt non sembra interessarsi. Vedremo cosa
succederà con Monkey's Audio 4.
Ciao, [proxima]

 inserito dei dati ridondanti.
Grazie per la tua risposta. Riguardo ai tool per il controllo dei CD sai
indicarmi un tool leggero adatto a questo scopo ? L'utilizzo del formato
RAR mi vede abbastanza recalcitrante perchè riduce la flessibilità d'uso
dei dati (non poter utilizzare direttamente un player audio). A parte che
aggiunge un altro step alla procedura d'archiviazione. Un' ultima cosa sul
tagging: Tag permette una conversione automatica ID3v1 --> APE1/2 ?
Ciao, Cat.one

 dei dati (non poter utilizzare direttamente un player audio).
Io lascerei qualsiasi player e mi butterei dritto su Foobar2000 
(
http://foobar2000.hydrogenaudio.org/
) di Palowski, un ex programmatore 
di winamp. Foobar puo' leggere direttamente archivi zip/rar.
La convenienza di non usare i Tag ID3v2.x e' confermata pure dalle scelte 
di questo player di non supportarli.
ciao, marco
-- 
Levare la "M" per rispondere

 Foobar puo' leggere direttamente archivi zip/rar.
Caratteristica unica nel settore. Sembra una feature fatta apposta per
l'accopiata RAR e APE.
Ciao, [proxima]

Tag permette una conversione automatica ID3v1 --> APE1/2 ?
Si.
Ciao, [proxima]

Ciao "[proxima]" ! Il Sun, 12 Jan 2003 01:44:56 +0100, nel messaggio
cvd12vo004mecn4hm...@4ax.com
 hai scritto:
 p> Già, seppure questi problemi sembrano ridursi.. rimangono ancora
 p> casi di persone che ottengono errori CRC in decodifica, anche con
 p> la 3.97.
 p> Io suggerirei anche di provare a decodificare il file appena
 p> encodato ancora prima di masterizzarlo, è un passo in più nella
 p> procedura di archiviazione ma consente di essere *sicuri* su
 p> eventuali errori.
Si, ma la funzione di verifica di Monkey non opera già in automatico
questa verifica?
 p> L'unico problema a quel punto rimane quello di un danneggiamento
 p> dei dati memorizzati ma è proprio a quel punto che entra in gioco
 p> RAR con i suoi recovery records. In questo modo i tuoi CD sono
 p> abbastanza al sicuro.
Beh' per evitare un danneggiamento in fase di scrittura su CD io usavo
CDCheck ed oggi uso Easy MD5 creator. Seppure questi tool non ti
garantiscono una possibilità concreta di recovery, le loro funzioni di
verifica sono certamente un'ottima garanzia che il CD sia stato prodotto
correttamente. Dopo queste verifiche l'unico modo per perdere dei dati è
rovinare il CD... cosa che comunque difficilmente sarebbe riparabile anche
con il CRC di WinRAR.
A proposito, che percentuale di recovery applichi ai file creati con
WinRAR?
 >> Si potrebbe utilizzare  altri lossless
 p> Si, io pensavo a LA (molto efficiente) che è veramente e da seguire
 p> con attenzione ma Monkey è attualmente quello da consigliare.
LA a mio parere è troppo lento per quello che offre. A quel punto
preferisco usare OptimFROG, anche nella nuova versione. E' lento ma almeno
comprime di più.
--
  __                                   _         _
/ __| ___  _ _   ___ __ _  _ __  __ _ | |_  _ _ (_) __ _
\__ \/ -_)| ' \ |_ // _` || '_ \/ _` ||  _|| '_|| |/ _` |
|___/\___||_||_|/__|\__,_|| .__/\__,_| \__||_|  |_|\__,_|
 
senza...@yahoo.it
   |_|  
www.senzapatria.cjb.net

comprime di più.
Sei sicuro di quello che dici ? hai fatto dei tests ?
Io ammetto di non aver verificato personalmente ma quello che emerge
da un recentissimo test in questo senso è esattamente il contrario:
http://web.inter.nl.net/users/hvdh/lossless/lossless.htm
LA 0.3c è risultato il migliore in quanto a percentuale di
compressione e anche le voci più autorevoli dei forums sembrano
confermare questi risultati.
Per il fatto che è molto lento sono assolutamente d'accordo (è anche
risultato nel test) ma bisogna considerare che è un progetto appena
nato e già il fatto di aver raggiunto e superato (in fatto di
compressione) altri prodotti che esistono da molto più tempo dimostra
che LA ha delle basi di partenza molto solide. Inoltre sono
incoraggianti per il futuro le parole di Michael Bevin (lo
sviluppatore) quando dice:
----------------------------------------------------------------------------------------------------------------------
I'm currently working on a new version of La, with a new compression
mode which is twice as fast, and currently achieves under 0.1% less
compression than the previous version. I've still got a few ideas I
want to try out before releasing, so it'll probably be a month or two
before anything new is released".
----------------------------------------------------------------------------------------------------------------------
Ciao, [proxima]

 comprime di più.
Sei fuori strada:
http://www.lossless-audio.com/comparison.htm
http://web.inter.nl.net/users/hvdh/lossless/lossless.htm


anche da un successivo verify che conferma il problema.
Qualcosa non mi è chiaro...verify di cosa ?
Se i files si corrompono durante il percorso o anche per altre cause
cosa c'entra Monkey's Audio ?
Ciao, [proxima]

 Qualcosa non mi è chiaro...verify di cosa?
Dei file ape, di cosa se no? Verify fallito e errore in riproduzione con 
winamp o anche il viceversa (riproduzione fallita e verify fallito). Da 
notare che spesso non funziona nemmeno con "ignore bistream info".
So benissimo anch'io che "questo/quello non dovrebbe verificarsi" se 
attuate certe procedure, ma con gli ape questo non discorso non vale per 
niente e, infatti, gli autori del programma non sanno come venirne fuori, 
ad un livello tale che ormai non possono far altro che minimizzare la 
cosa, evidentemente loro hanno creato il formato ma non lo usano a tutto 
tondo come il sottoscritto e tanti altri.


dc++)
Forse parliamo di due cose diverse. Ti ripeto che il problema non è
dovuto a sharing quindi a possibili corruzioni durante il percorso per
i quali basterebbe un recovery record ma a fattori completamente
diversi di cui sopra. Che poi il problema non sia ben chiaro neppure a
Klemm e Matt è un dato di fatto ma la sua natura è chiara e non ha
nulla a che vedere con trasmissioni o eventuali corruzioni dei files
in NG binari o DC++
Ciao, [proxima]

Ciao "[proxima]" ! Il Sun, 12 Jan 2003 15:48:49 +0100, nel messaggio
ces22vscrtb36jso7...@4ax.com
 hai scritto:
 > Ci tengo a precisare che io non ho mai avuto problemi di questo
 > tipo e spesso questi si manifestano in presenza di sistemi
 > instabili e/o overclockati.
Nemmeno io... anche se il mio sistema non è per niente overclockato.
Siamo alle solite secondo me: lamentele fatte senza cognizione di
causa.
Raccontami di un programma che tratta dati "sensibili" che in caso di
un sistema overclockato non perda consistenza! Io per esempio il
sistema informativo aziendale non lo farei girare su un sistema
potenzialmente instabile. A mio parere tutto dipende da quanto si
hanno a cuore i dati che si trattano!
 >> cosa che comunque difficilmente sarebbe riparabile anche con il
 >> CRC di WinRAR.
 > Invece è molto probabile che si recuperi, qui non stiamo parlando di
 > CRC (che è sempre una garanzia "passiva") ma di dati ridondanti
 > inseriti all'interno dell'archivio.
Ti è mai capitato? Hai esperienze in merito? A me è successo una sola
volta e con una percentuale dell'1% non ho recuperato niente. Fatti
un po' i conti!
 >> LA a mio parere è troppo lento per quello che offre. A quel punto
 >> preferisco usare OptimFROG, anche nella nuova versione. E' lento
 >> ma almeno comprime di più.
 > Sei sicuro di quello che dici ? hai fatto dei tests ?
 > Io ammetto di non aver verificato personalmente ma quello che
 > emerge da un recentissimo test in questo senso è esattamente il
 > contrario:
 > 
http://web.inter.nl.net/users/hvdh/lossless/lossless.htm
 > LA 0.3c è risultato il migliore in quanto a percentuale di
 > compressione e anche le voci più autorevoli dei forums sembrano
 > confermare questi risultati.
No, purtroppo non ho fatto test "scientificamente" validi sulle
ultime versioni (anche se in questo campo nessun test può avere una
valenza scientifica... almeno quando il campione è così limitato come
il test che hanno svolto); erano solo mie supposizioni basate
sull'utilizzo. Comunque non metto in dubbio quello che mi dici. Spero
solo che Ghido continui nello sviluppo del codec OptimFROG che a mio
parere è uno dei migliori attualmente sul mercato. Comunque a mio
parere, e spero di non dire una cosa banale, mi sembra che oggi
esistano sostanzialmente due tipi di codec lossless: quelli che
puntano tutto sulla massima compressione ottenibile a scapito della
lentezza e quelli che invece cercano un buon compromesso tra velocità
e compressione. OptimFROG e LA sembrano ricadere entrambi nella prima
categoria. Alla lunga speriamo che la competizione ci dia un prodotto
migliore. :)
Ciao!
Senzapatria


migliore. :)
Lo seguiremo !
Ciao, [proxima]

 in NG binari o DC++
Quando uno e' abituato a scambiare qualsiasi file in quegli ambienti, e' 
anche abituato a scontrarsi a volte con file corrotti, anche a causa di 
problemi di trasmissione (perche' sull'hd del mittente funzionavano e le 
modalita' di trasferimento scelte erano ok, non come qualche casino che 
puo' capitare ad un neofita con i trasferimenti binari-ascii sugli ftp), 
ma quando i file corrotti aumentano e questo aumento si verifica SOLO e 
su un ben specificato formato (.ape), siamo di fronte ad un problema piu' 
che reale. Non mi interessa se non e' un problema della struttura ape, 
del suo encoder o suo decoder, sta di fatto che il rischio e' piu' che 
presente.
Riassuntino finale: condizioni di sistema/linea che per tutti gli altri 
file sembrano andare per il 99% dei casi, non lo sono per i file ape (o 
sistema Monkey in generale). Inoltre, cd-r masterizzati con all'interno 
file lossless di vari formati (ape inclusi), nel caso salti fuori in 
controlli futuri un qualche problema di non corrispondenza crc32 o md5, 
questo problema e' quasi sempre focalizzato sui file ape, ma che strano.


 wrote:
Ok, vedo che il problema è un pò più complesso, cerco di spiegarmi
meglio su quello che intendevo dire. Mi scuso se ti sono sembrato
"poco elastico" ma capirai che quello che succede è molto anomalo e un
file che si "copia" o si "gestisce" non può danneggiarsi senza un
motivo valido. Sperando di non fare casini con la formattazione, cerco
di schematizzare il problema prendendo in esame tutti i casi possibili
di errore dato che non ha senso prenderne in considerazione solo uno:
--------------------                         --------------------
hw stabile             ----->           hw stabile
WAV-->APE    trasmissione    APE-->WAV
       ok                   ok                   ok
--------------------                         --------------------
Quello sopra  rappresenta un caso perfettamente ideale.
----------------------                       ----------------------
hw instabile           ----->           hw stabile
WAV-->APE     trasmissione    APE-->WAV
APE difettoso          ok            errore
----------------------                       ----------------------
Qua, in presenza di hardware "instabile" monkey's potrebbe avere
qualche problema al momento della codifica. Se si usa il verify, in
teoria, si dovrebbe evidenziare l'errore ma dato che siamo in presenza
di hardware instabile e la verifica è effettuata dallo stesso monkey's
(che non lavora bene) si potrebbero avere anche risultati falsati.
Ecco perchè io consigliavo di decodificare e controllare se il WAV
originale e quello decodificato erano uguali (e questo lo si può fare
con una banale funzione di tipo hash).
---------------------                        --------------------
hw stabile             ----->          hw instabile
WAV-->APE    trasmissione    APE->WAV
      ok                     ok                errore
---------------------                        --------------------
Questo potrebbe essere il caso più difficile da risolvere dato che il
file APE arriva intatto al destinatario e il problema sta proprio nel
problema che ha monkey's a decodificare su sistemi "instabili".
--------------------                            -------------------
hw stabile             ----->              hw stabile
WAV-->APE    trasmissione      APE-->WAV
        ok                errore                errore
--------------------                            -------------------
Questo è il caso di trasmissione con errori, in questo caso Monkey's
non ha colpe perchè non è direttamente coinvolto.
Come vedi è abbastanza chiaro che i recovery records possono risolvere
SOLTANTO l'ultimo caso, ovvero quando ci sono errori in trasmissione
ma se il file di partenza è difettoso (caso 2) o anche nel caso 3 i
dati ridondanti non risolvono il problema che invece è strettamente
legato all'accoppiata monkey's - sistema "instabile".
Inoltre non riesco a capire perchè giudichi il formato APE strutturato
male: se il file che arriva a destinazione ha anche un solo byte
differente mi sembra una cosa abbastanza comprensibile il fatto che il
decoder si rifiuti di funzionare, a quel punto si potrebbe "forzare"
la decodifica ignorando gli errori che comunque rimangono (sempre per
cause estranee a monkey's). Semmai possiamo dire che si potrebbe
IRROBUSTIRE il formato con l'utilizzo dei recovery records ma il fatto
di irrobustirlo non vuol dire che sia disegnato male.
Il fatto che io non shari files APE (fra l'altro non posso con il mio
modem 56k) e che non mi sia mai imbattuto in problemi di questo tipo
(io uso il lossless solo per archivi personali) non vuol dire che non
possa distinguere tra questi casi che sicuramente sono tutti quelli
possibili. Naturalmente le cause del problema rimangono oscure,
occorrerebbe fare delle verifiche prendendo in esame tutti i casi di
cui sopra, un lavoro sicuramente molto delicato e che non sempre porta
ad una facile soluzione.
Ciao, [proxima]

 cause estranee a monkey's).
Appunto spesso non serve a niente, come testimoniato da altri pure sui 
forum piu' conosciuti.
A questo punto per levarmi di torno un'altra variabile non resta che 
farmi la codifica in ape di circa 10 CD ma ricavandomi l'hash di ogni wav 
per poi confrontarlo con quello degli ape corrispondenti, "sceckerare" il 
tutto e mettere in sharing.
Una cosa e' piu' che certa: dover arrivare a pignolerie estreme e 
perditempo per sopperire a lacune di un prodotto e' il metodo migliore 
per allontanare tantissime persone da quest'ultimo e dunque ridurre 
drasticamente la diffusione del formato e del suo materiale circolante.


Puoi postare qualche link relativo alle supposizioni e le discussioni
e le prove fatte intorno a questo problema?
Ciao, grazie
--
[dentament]
Mail: togli .remove. dall'indirizzo
GPG/PGP public key: 
http://utenti.lycos.it/dentament/gpg_key.txt

e le prove fatte intorno a questo problema?
Trovi molti vecchi post in questo NG e anche sui soliti forums:
http://www.hydrogenaudio.org/
http://www.monkeysaudio.com/cgi-bin/YaBB/YaBB.cgi
Ciao, [proxima]