Newsgroup: it.comp.os.amiga
Titolo: Tool per MP3

Salve, mi servirebbe un software, possibilmente da linea di comando,
che faccia uno scan di un file MP3 e lo spezzetti in piu' MP3 quando
trova una pausa lunga un valore in secondi definito dall'utente.
Esiste un tool del genere, o in alternativa uno open source di cui sia
possibile portarlo su Amiga?
Varthall



Come complicarsi la vita eh? :p
a parte gli scherzi, mi pare non ci sia una cosa del genere..o se c'č,
mi sembra cosě su due piedi..inutile.

 mi sembra cos? su due piedi..inutile.
Mi sarebbe utile per trasferire alcuni dischi in vinile e cassette in
mp3, per dividere le canzoni/pezzi audio in singoli file. Non e' molto
comodo scorrere file MP3 da un'ora usando solo l'avanzamento veloce
dell'autoradio ^^
Varthall

 dell'autoradio ^^
Ma usare un comune programma di editing audio su qualsiasi piattaforma, 
capace di visualizzare la forma d'onda del suono no, eh? Dove vedi la 
linea piatta per tre-quattro secondi, quelle sono le pause tra una 
canzone e l'altra. Un po' di taglia/incolla e sei a posto.
Se hai una qualsiasi altra piattaforma oltre ad Amiga, cerca Audacity su 
sourceforge, non fa proprio quello che vuoi tu ma ti semplifica la vita.
saluti
p.bes

 sourceforge, non fa proprio quello che vuoi tu ma ti semplifica la vita.
Basta HDRec per lo scopo, l'ho gia' usato per modificare mp3 in
passato.
Varthall

passato.
visto che hai già trovato la soluzione? :)
oppure volevi qualcosa da portare su os4? :p
cmq sia di programmi opensource da portare ci sono per fare editing
audio e magari anche video.

 audio e magari anche video.
Cercando in rete oggi ho trovato questo, provo a vedere se riesco a
portarlo: 
mp3splt.sourceforge.net
Varthall

portarlo: 
mp3splt.sourceforge.net
toglimi una curiosità, ma quandi tenti di fare un porting, la prima
volta basta che fai un ./configure da sh e poi fai make?
oppure devi modificare il codice sorgente?
ora finalmente ho trovato i file mancanti dalla versione gcc per 68k
(rm, sek e chmod) e volevo provare, ma da sempre errori sopratutto
quando tento di fare un ./configure.

quando tento di fare un ./configure.
ho provato con questo programmino che hai trovato..
sono entrato in sh
./configure
lui scrive 
kGF e muore li..
che palle!!
a parte hello world non si compila nulla...

 oppure devi modificare il codice sorgente?
Si', in genere questa e' la procedura, anche se per semplificare il
lavoro uso una stringa con parametri aggiuntivi (si trova sulla guida
Porting For Dummies su OS4depot, in parte potrebbe esser utile anche
per 68k) che crea un makefile gia' pronto all'uso. Da qui in poi c'e'
quasi sempre bisogno di fare modifiche nel makefile (librerie
mancanti, problemi di path) o nel codice (header mancanti, funzioni
mancanti da rimpiazzare con funzioni equivalenti, problemi da
incompatibilita' tra versioni GCC usate, ecc...).
Varthall

 a parte hello world non si compila nulla...
Dice solo quello?
Occhio che per lanciare script come configure bisogna usare una bash
shell o compatibile, oppure affidarsi al crosscompiling.
Varthall

Un programma che faccia quello che dice Varthall esiste ed è Open
Source. Si chiama gramofile.

incompatibilita' tra versioni GCC usate, ecc...).
da qui zero assoluto, buio totale ..
a me interesseva solo fare una semplice compilata e vedere che viene
fuori ..
vorrei togliermi questa soddisfazione..

 wrote:
visto che c'era Tale of Tamar per 68k? :)

shell o compatibile, oppure affidarsi al crosscompiling.
io ho solo il comando sh..non trovo o non so come si chiama una shell
per 68k tipo abc-shell per os4.
c'è il gcc crosscompiling per amithlon hostato su amigaos..ma non ho
capito come integrarlo al gcc ..

 Source. Si chiama gramofile.
Grazie per la segnalazione. Ha un bel po' di funzioni interessanti e
non usa GUI che rende un port molto piu' veloce. Purtroppo usa
funzioni di campionamento e di riproduzioni audio, che richiedono un
po' di codice per interfacciarsi ad AHI.
Varthall

 capito come integrarlo al gcc ..
Quello di Zerohero?
Varthall

 vorrei togliermi questa soddisfazione..
/MODO SUPER FLAME ON
Passa a un sistema serio, ti consiglio OSX, dove bastano (quasi sempre):
./configure
make
/MODO SUPER FLAME OFF
Scherzi a parte, basta mettere mano per 10 minuti a XCode e ti accorgi 
di essere avanti anni luce, proprio un altro pianeta, e per funzioni e 
per documentazione... StormC, Autodoc e accrocchi di OS4 ti passa anche 
la voglia solo di PENSARCI.
Poi magari tra ALTRI 15 anni AmigaOS 5.1 verrà reso Unix Compliant e un 
pochino più moderno delle classi ReAction (brrr)...

 pochino più moderno delle classi ReAction (brrr)...
Ecco, qui invece ti devo necessariamente dare torto. Perché diavolo un 
buon sistema operativo dovrebbe avere come base Unix? A me onestamente 
tutto ciò che ha a che fare con Posix e con la filosofica unixiana ha 
scassato la minchia, se non altro perché sembra che al di là di 
Microsoft, e al di là dei dialetti Unix, non si possa davvero fare 
nient'altro.
p.bes

paolo besser ha scritto:

Ti devo necessariamente :) far notare che non ho detto che senza Unix il 
sistema NON è buono... anzi!!
Siccome mi pareva di capire che Seya avrebbe gradito ANCHE poter 
compilare i programmi Unix, gli ho fatto notare che OSX, 
intelligentemente, lo può fare... e Apple ha fatto centro perché quasi 
tutto il software free di OSX proviene da Unix/Linux. Su OS4 si stanno 
sforzando di fare una cosa simile, ma è ancora lontana dal "./configure 
&& make" di OSX.
XCode supporta *anche* progetti Unix, ma in realtà i miei complimenti 
erano rivolti a *cocoa*, alle centinaia di framework già pronti (o di 
terze parti) che possiede e alla marea di tutorial/documentazione 
presenti per esso.
Forse solo MUI ha qualcosa in comune con quel paradigma, ma tutte le 
classi MUI messe assieme saranno si e no il 2% di quelle già pronte 
Cocoa, tralasciando poi il fatto che alla fine si rimane pur sempre 
dentro Intuition, quindi GUI, e dei primi anni 90; fin troppo avanzata 
per QUELL'epoca, considerando dove è arrivata (ovvero: AROS e 
OS4/MorphOS) :). Mentre Cocoa prevede framework anche per la grafica, 
l'audio, e chi più ne ha più ne metta.
L'unico pregio di Unix/Posix è l'enorme diffusione (visto che sono tra i 
sistemi più antichi della terra) e una progettazione forse più accorta, 
specialmente in relazione alla sicurezza.
Ma l'ambiente (marasma di file in /usr /bin /etc /etc :D) e le API di 
base, si portano appresso il peso di 50 anni.

&& make" di OSX.
io speravo che bastasse prendere un sorgente e fare presto anche a
fare una compilata veloce per vedere che viene fuori..
tanto per provare..ma la reatà è ben diversa :(

 la voglia solo di PENSARCI.
Personalmente trovo XCode tremendamente scomodo... dopo averlo usato x 
un progetto commerciale sono passato ai vecchi Makefile x quelli successivi.
In particolare l'editor e` molto limitato, la modalita` a lavoro a 
finestre multiple e` troppo disordinata, i settings del compilatore e 
del linker sono sparsi dappertutto e spesso e` necessario modificarli in 
2 o piu` punti perche` le cose funzionino nel modo giusto e la gestione 
della compilazione distribuita e` perlomeno discutibile (funziona solo 
con macchine con OSX tutte con la stessa versione di xcode, mentre io 
utilizzando il distcc via makefile riesco a usare anche macchine con 
diverse versioni di osx e un pc con linux), per non parlare del ridicolo 
consumo di ram del solo IDE.
Notate che non parlo di progetti piccoli, l'ultimo su cui sto lavorando, 
il porting di Jack Keane su OSX/Linux,
Come IDE sia VS (dal 6 in su) o CodeBlocks (su windows), che KDE o 
Anjuta (su Linux), che Eclipse (su tutti i sistemi) gli sono nettamente 
superiori.
Questo per quanto riguarda la programmazione C/C++, uso poco Objective 
C, solo quando non ne posso fare a meno :)
--
Bye,
  Gabry

On Thu, 27 Mar 2008 15:10:51 +0100, Gabriele Greco wrote:
Stavo cercando appunto qualcosa di alternativo ad XCode su OSX, cosa mi
consigli??
Io sono del genere CubicIDE/DevC++/NetBeans sappilo :)
In alternativa un editor con sintax highlight code folding e roba simile
ci sta su osx??
-- 
Ciao!
ShInKurO
http://shinkuro.amiga.it

 superiori.
Ok, ma con Eclipse non sviluppi solo per OSX, né tantomeno per Amiga :)
Non discuto che ci siano IDE superiori, discutevo del fatto che XCode lo 
trovi integrato perfettamente nell'OS, e in pochi minuti inizi a 
programmare per OSX - motivo del confronto, UNIX e volendo anche Java. 
Per Amiga invece puoi programmare solo per Amiga... a parte forse 
programmi da console in C/C++ standard.
Poi è chiaro, non mi sognerei mai di usare XCode per applicazioni Java...
 > Questo per quanto riguarda la programmazione C/C++, uso poco Objective
 > C, solo quando non ne posso fare a meno :)
Beh, alla fine non è il linguaggio, ma la gestione a oggetti dei 
framework la cosa che si deve imparare :)
Due righe di codice e hai già un'applicazione con un'interfaccia su 
misura, personalizzabile semplicemente usando il mouse.
Quanto ci metti a fare la stessa cosa con MUI o peggio Reaction? Anche 
per MUI c'erano dei generatori di codice... ma erano un incubo da far 
funzionare, e infatti furono tutti abbandonati :-)

 imparare MUI e in generale tutto il BOOPSI?
Non è colpa dell'IDE di riferimento su Amiga (CubicIDE), è colpa della
scarsa ed obsoleta documentazione. Per scrivere la mia guida ho dovuto
fare i salti mortali, tra documenti non aggiornati, la maggior parte in
inglese, articoli su riviste e domande ai poverelli che mi capitavano in
chat... Ed alla fine non ho ancora scritto nulla su come sfruttare al
meglio il meccanismo di notificazione MUI, ci sono scritte solo le basi,
almeno per come la vedo io...
CubicIDE dal canto suo è un ottimo strumento di supporto, manca di
alcune cose, ma come editor è uno dei migliori, non solo su Amiga...


 ci sta su osx??
Io uso GVIM su qualunque piattaforma, ha syntax highlighting, code 
completion, tag e tutto quello di cui un editor puo` aver bisogno, se lo 
usi in modalita` "mswin" (:behave mswin, il default su diverse 
piattaforme), non e` neppure troppo ostico. Una volta che si e` abituati 
ad avere modalita` editing/comandi separate e i comandi "componibili", 
la comodita` e` tale che non si torna + indietro :)
Bye,
  Gabry

 funzionare, e infatti furono tutti abbandonati :-)
Rimpiango la facilita` con cui con MUI si facevano le interfacce via 
linea di comando, quella sintassi gerarchica con le , e l'end. :)
Sto scrivendo ora (x un progetto a lavoro) un wrapper a GTK in C++ che 
permette di scrivere le interfacce in modo vagamente simile a quello che 
si poteva fare con le macro di MUI.
In ogni caso i generatori di codice ormai non li usa + nessuno, si 
tengono le interfacce in XML (o altri formati proprietari) e si 
costruiscono a runtime, oppure si definisce l'interfaccia inline.
Bye,
  Gabry

 costruiscono a runtime, oppure si definisce l'interfaccia inline.
Che è un po' la direzione di Core Animations e degli elementi di
Composer. La transizione è lunga (e a volte dolorosa per lo sviluppo) ma
dobbiamo anche considerare il punto di partenza e l'esigenza di gestire
una rivoluzione come se fosse un'evoluzione.
Fino alla settimana scorsa ho dovuto sviluppare un paio di applicazioni
di prova su iPhone senza il supporto di Interface Builder. Dopo anni di
abitudine a un workflow che lo includeva sulle prime è stato complicato;
poi mi sono reso conto che realizzare un'interfaccia grafica
direttamente da codice è tutt'altro che complicato e lento (anche se
sono dovuto tornare al buon vecchio design su carta per riuscire a
tradurre la concettualizzazione in qualcosa di riconoscibile).
marc

 tradurre la concettualizzazione in qualcosa di riconoscibile).
Il progetto GTK che sto avviando ora penso che, sperimentalmente, lo 
faro` interamente con interfacce inline. Ovviamente i moduli di 
interfaccia grafica saranno separati da quelli che implementano la 
funzionalita`, voglio vedere se lo sviluppo e` piu` comodo rispetto ai 
progetti precedenti che usavano glade x l'interfaccia, di sicuro ci 
saranno meno moduli di "hook" e callback statiche varie e potro` 
veramente creare degli oggetti per ognuna delle finestre.
Sara` un progetto grosso con svariate decine di maschere diverse. Nel 
progetto passato abbiamo avuto diversi problemi con le interfacce glade 
nello sviluppo parallelo:
Il merge automatico di due file .glade fornito da CVS e` assolutamente 
inconsistente e inutilizzabile. Al contrario CVS e` piuttosto bravo ad 
eseguire il merge di due file sorgenti su cui si e` lavorato in parallelo.
I progetti piu` grossi non usano gui builder anche per questo motivo.
Non ho idea di come si possa mettere un file nib di Interface Builder in 
CVS/SVN, ma ho idea che qualche problema con lo sviluppo parallelo lo 
dia anche quello (come lo danno i progetti di XCode rispetto ai Makefile)
Bye,
  Gabry