Per questo consigliavo l'uso dell'opzione --ignore, che dovrebbe appunto servire per ignorare quanto scritto nell'header, il rapporto tra le dimensioni in byte è corretto.
EDIT: Ma da dove esce test.wav? non è l'output del primo comando, lo hai prodotto allo stesso modo?
Ultima modifica di marcoc1712 : 04-05-2016 a 17:37
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
ehm... lì serve a ben poco. È proprio quella istanza di sox che genera l'header sbagliato (quello che gli arriva "a monte" è giusto, quindi è inutile ignorarlo). È quanto segue (LMS? SL?) che invece usa quell'informazione e (giustamente) considera terminato il file a quel punto.
Ho sottomesso un bug report: https://bugs.debian.org/cgi-bin/bugr...cgi?bug=823417
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Non vorrei fosse prorpio squeezelite-R2, a differenzda idi squeezelite legge l'header e potrebbe essere tratto in errore... Riesci a provare ad eseguire il file su Squeezelite 'normale' (non l'ultima versione che include R2)?
In ogni caso è un errore di SOX, non credo valga la pena di rincorrerlo nei diversi players.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Appurato che questo è un problema dovuto a SOX ed in merito al quale posso fare ben poco, sarebbe interessante verificare se tutti quelli sperimentati sono riconducibili a questo o se esiste una diversa casistica, come pareva essere dalla prime segnalazioni.
Attendo vs. segnalazioni nel caso riscontriate roblemi non riconducibili a questo, ma al momento chiudo il problema come 'esterno' a C-3PO.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Aggiornamento: se anziché "wav" in uscita si utilizza il formato "nativo" di sox, il problema non si manifesta:
codice:$ cat orig/STE-000.wav | /usr/bin/sox -V3 -t wav - -t sox -r 384000 -b 32 --buffer=8192 - gain -h rate -v -M -b 90.7 384000 > test.sox /usr/bin/sox: SoX v14.4.1 Input File : '-' (wav) Channels : 2 Sample Rate : 48000 Precision : 24-bit Duration : 00:38:06.69 = 109761216 samples ~ 171502 CDDA sectors Sample Encoding: 24-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Output File : '-' (sox) Channels : 2 Sample Rate : 384000 Precision : 32-bit Duration : 00:38:06.69 = 878089728 samples ~ 171502 CDDA sectors Sample Encoding: 32-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' /usr/bin/sox INFO sox: effects chain: input 48000Hz 2 channels /usr/bin/sox INFO sox: effects chain: gain 48000Hz 2 channels /usr/bin/sox INFO sox: effects chain: rate 384000Hz 2 channels /usr/bin/sox INFO sox: effects chain: output 384000Hz 2 channelsa questo punto, ho voluto verificare cosa succedesse ad es. con aiff:codice:soxi test.sox Input File : 'test.sox' Channels : 2 Sample Rate : 384000 Precision : 32-bit Duration : 00:38:06.69 = 878089728 samples ~ 171502 CDDA sectors File Size : 7.02G Bit Rate : 24.6M Sample Encoding: 32-bit Signed Integer PCM Comment : 'Processed by SoX'
...e qui già viene fuori una sopresa: quel warning che ci avvisa che "il file è troppo grande e l'header potrebbe non essere accurato" (con wav non accadeva).codice:$ cat orig/STE-000.wav | /usr/bin/sox -V3 -t wav - -t aiff -r 384000 -b 32 --buffer=8192 - gain -h rate -v -M -b 90.7 384000 > test.aiff /usr/bin/sox: SoX v14.4.1 Input File : '-' (wav) Channels : 2 Sample Rate : 48000 Precision : 24-bit Duration : 00:38:06.69 = 109761216 samples ~ 171502 CDDA sectors Sample Encoding: 24-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Output File : '-' (aiff) Channels : 2 Sample Rate : 384000 Precision : 32-bit Duration : 00:38:06.69 = 878089728 samples ~ 171502 CDDA sectors Sample Encoding: 32-bit Signed Integer PCM Endian Type : big Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' /usr/bin/sox INFO sox: effects chain: input 48000Hz 2 channels /usr/bin/sox INFO sox: effects chain: gain 48000Hz 2 channels /usr/bin/sox INFO sox: effects chain: rate 384000Hz 2 channels /usr/bin/sox INFO sox: effects chain: output 384000Hz 2 channels /usr/bin/sox WARN aiff: file size too big for accurate AIFF header
Avvio soxi e, seconda sorpresa: invece di rispondere pressoché istantaneamente (come avveniva sia con formato wav che "sox"), qui ci mette una vita: a giudicare da htop, sta leggendo sequenzialmente l'intero file!
Quando alla fine ritorna, siamo punto e a capo: stesso problema che con wav.
codice:$ soxi test.aiff Input File : 'test.aiff' Channels : 2 Sample Rate : 384000 Precision : 32-bit Duration : 00:14:48.59 = 341218816 samples ~ 66644.3 CDDA sectors File Size : 7.02G Bit Rate : 63.2M Sample Encoding: 32-bit Signed Integer PCM Comment : 'Processed by SoX'
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Non mi risulta, ma è possibile ci sia un limite da specifiche nelle dimensioni del file nei formati PCM?Aggiornamento: se anziché "wav" in uscita si utilizza il formato "nativo" di sox, il problema non si manifesta:
codice:$ cat orig/STE-000.wav | /usr/bin/sox -V3 -t wav - -t sox -r 384000 -b 32 --buffer=8192 - gain -h rate -v -M -b 90.7 384000 > test.sox /usr/bin/sox: SoX v14.4.1 Input File : '-' (wav) Channels : 2 Sample Rate : 48000 Precision : 24-bit Duration : 00:38:06.69 = 109761216 samples ~ 171502 CDDA sectors Sample Encoding: 24-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Output File : '-' (sox) Channels : 2 Sample Rate : 384000 Precision : 32-bit Duration : 00:38:06.69 = 878089728 samples ~ 171502 CDDA sectors Sample Encoding: 32-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' /usr/bin/sox INFO sox: effects chain: input 48000Hz 2 channels /usr/bin/sox INFO sox: effects chain: gain 48000Hz 2 channels /usr/bin/sox INFO sox: effects chain: rate 384000Hz 2 channels /usr/bin/sox INFO sox: effects chain: output 384000Hz 2 channelsa questo punto, ho voluto verificare cosa succedesse ad es. con aiff:codice:soxi test.sox Input File : 'test.sox' Channels : 2 Sample Rate : 384000 Precision : 32-bit Duration : 00:38:06.69 = 878089728 samples ~ 171502 CDDA sectors File Size : 7.02G Bit Rate : 24.6M Sample Encoding: 32-bit Signed Integer PCM Comment : 'Processed by SoX'
...e qui già viene fuori una sopresa: quel warning che ci avvisa che "il file è troppo grande e l'header potrebbe non essere accurato" (con wav non accadeva).codice:$ cat orig/STE-000.wav | /usr/bin/sox -V3 -t wav - -t aiff -r 384000 -b 32 --buffer=8192 - gain -h rate -v -M -b 90.7 384000 > test.aiff /usr/bin/sox: SoX v14.4.1 Input File : '-' (wav) Channels : 2 Sample Rate : 48000 Precision : 24-bit Duration : 00:38:06.69 = 109761216 samples ~ 171502 CDDA sectors Sample Encoding: 24-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Output File : '-' (aiff) Channels : 2 Sample Rate : 384000 Precision : 32-bit Duration : 00:38:06.69 = 878089728 samples ~ 171502 CDDA sectors Sample Encoding: 32-bit Signed Integer PCM Endian Type : big Reverse Nibbles: no Reverse Bits : no Comment : 'Processed by SoX' /usr/bin/sox INFO sox: effects chain: input 48000Hz 2 channels /usr/bin/sox INFO sox: effects chain: gain 48000Hz 2 channels /usr/bin/sox INFO sox: effects chain: rate 384000Hz 2 channels /usr/bin/sox INFO sox: effects chain: output 384000Hz 2 channels /usr/bin/sox WARN aiff: file size too big for accurate AIFF header
Avvio soxi e, seconda sorpresa: invece di rispondere pressoché istantaneamente (come avveniva sia con formato wav che "sox"), qui ci mette una vita: a giudicare da htop, sta leggendo sequenzialmente l'intero file!
Quando alla fine ritorna, siamo punto e a capo: stesso problema che con wav.
codice:$ soxi test.aiff Input File : 'test.aiff' Channels : 2 Sample Rate : 384000 Precision : 32-bit Duration : 00:14:48.59 = 341218816 samples ~ 66644.3 CDDA sectors File Size : 7.02G Bit Rate : 63.2M Sample Encoding: 32-bit Signed Integer PCM Comment : 'Processed by SoX'
Cosa succede se lanci SOXI --ignore?
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
provato anche con "wavpcm" (vedi "man soxformat"), una variante non standard di wav... niente da fare.
La cosa curiosa è che, scegliendo un formato di uscita a 24bit anziché a 32bit, la durata (sbagliata) del file diventa ancora più breve, circa la metà!
(...ed il bitrate riportato -errato- sale ancora)codice:$ soxi test.wav Input File : 'test.wav' Channels : 2 Sample Rate : 384000 Precision : 24-bit Duration : 00:07:02.56 = 162261845 samples ~ 31691.8 CDDA sectors File Size : 5.27G Bit Rate : 99.7M Sample Encoding: 24-bit Signed Integer PCM
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
in alcuni probabilmente sì (ad es. aiff, con cui infatti sox emette un warning... anche se dubito che "l'imprecisione" di cui parla il warning abbia nulla a che vedere con l'errore madornale che c'è in questi casi).
che dà errore, non accetta quella opzione nella modalità "info".
Comunque è curioso che invece mediainfo riporti i dati corretti (e senza segnalare errori).
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Marco hai aggiornato C-3PO...adesso le impostazioni le prende al primo (re)play....tranne il passaggio da MAX supportata a Max Sincro...
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando
