|
Akkurat kommet hjem fra ferie, så jeg har ikke fått gjort så mye annet enn å hatt mine to pc-support kompiser innom for å få litt kvalifisert hjelp. Det lykkes dem ikke å få til noe på en kveld så de skulle se på det hjemme hos seg selv. Hva status er vet jeg ikke før jeg har fått snakket med dem. Har en uke ferie igjen nå, så jeg håper å få litt fremdrift hvis de kan hjelpe meg. Vi får evt be pent om litt fjernsupport om ting står i stampe?Ja...det suger, om det faktisk blir endelig!
Kommer du noen vei, Gutman? Eller sliter du deg i håret?(Kjenner godt til den!)
Ingen grunn til å ikke gjøre det og rapportere tilbake. Dette er jo tross alt MPD-tråden
Ja det ordner seg nok på et visAkkurat kommet hjem fra ferie, så jeg har ikke fått gjort så mye annet enn å hatt mine to pc-support kompiser innom for å få litt kvalifisert hjelp. Det lykkes dem ikke å få til noe på en kveld så de skulle se på det hjemme hos seg selv. Hva status er vet jeg ikke før jeg har fått snakket med dem. Har en uke ferie igjen nå, så jeg håper å få litt fremdrift hvis de kan hjelpe meg. Vi får evt be pent om litt fjernsupport om ting står i stampe?Ja...det suger, om det faktisk blir endelig!
Kommer du noen vei, Gutman? Eller sliter du deg i håret?
EUR 120 - Tror jeg bestiller en selv og tester.
Cubox with kernel 3.3.1 and Ubuntu Core 12.04 beta 2 - SolidRun CuBox Wiki
Apropos det: Etter å ha lagt merke til at AIFF låter betydelig bedre enn komprimert, har jeg prøvd å omgå dette ved å bruke større buffer og diverse andre ting, men har kommet til konklusjonen at jeg muligens må konvertere alt til AIFF. Et nederlag, menmen..Det er ikke et nederlag - bare tørre faktaJeg er villt begeistret for lydkvaliteten fra Linux. Den er helt magisk
Keep it Simple, Silent and Smart - PSU 84-130
Tror ikke det var problemet, problemet var at de var over 192khz. Men jeg kan jo dobbelsjekke det. Det skulle vært rart at et Apple-format skal fungere fint med FFMPEG, men ikke vanlige AIFF. Det er jo ikke helt logisk. Tror den separete AIFF-dekoderen er i bruk ved alle typer AIFF (har prioritet foran FFMPEG)Det er ikke et nederlag - bare tørre fakta
Det sier seg selv at det å første komprimere og så i realtime skal en dekomprimere - noe som gir helt unødvendig prossesering som igjen modulerer strømforsyninger etc...
Men det kan hende at WAV spiller bedre enn AIFF....
Sjekk dette ved å konvertere en AIFF til WAV og sammenlign..
Årsaken til at WAV kan spille bedre på linux er at AIFF i "Apple verden" ikke er ren AIFF, men AIFF-C/sowt som egentlig er et komprimertformat, men data er ikke komprimert...
Fil header er ikke identisk med Apple AIFF og standard AIFF..
Da er det mulig at MPD gjør noen ekstra instruksjoner ved lesing..
WAV kan tagges i iTunes (og med andre verktøy) og MPD trenger en folder.jpg fil med album cover uansett..
EDIT: Hmmm.. tok som en "selvfølge" at de AIFF filene som normalt brukes er konvertert med iTunes og er AIFF-C/sowt..
@Man de AIFF filene som ikke ville spille var standard AIFF og ikke konvertert med iTunes...
De AIFF som spillte var konvertert med iTunes og var AIFF-C/sowt.
Da vet du vel allerede om MPD bruker forskjellige bibliotek med AIFF og AIFF-C/sowt
Alle WAV filene på 352.8k spilte, alle AIFF filene på 352.8k som var kodet med iTunes spilte, men de AIFF filene på 352.8k som IKKE var kodet med iTunes spilte IKKE.
Med exaU2I USB -> I2S kortet har jeg drivere hvor jeg kan sende data som big-endian eller little-endian (uansett hvilken endian koding lyd filen har), og hvor exaU2I stokker om big-endian til little-endian..
Skal få tatt et bilde av en oppgradert versjon og lagt ut her.
#!/bin/bash
SRC="/srv/md0/music/"
SRCNAME="folder.jpg"
DSTNAME="Folder.jpg"
find "$SRC" -type f -name "$SRCNAME" -print0 | while read -d $'\0' FILE
do
mv -v "$FILE" "$(dirname "$FILE")/$DSTNAME"
doneJeg testet scriptet på Debian Wheezy, men laget det opprinnelig på Squeeze. Sikker på at det ikke har blitt noe kødd med kopieringen?
read [-ers] [-a aname] [-d delim] [-i text] [-n nchars] [-N nchars] [-p prompt] [-t timeout] [-u fd] [name ...]
One line is read from the standard input, or from the file descriptor fd supplied as an argument to the -u option, and the first word is assigned to the first name, the second word to the second name, and so on, with
leftover words and their intervening separators assigned to the last name. If there are fewer words read from the input stream than names, the remaining names are assigned empty values. The characters in IFS are used
to split the line into words. The backslash character (\) may be used to remove any special meaning for the next character read and for line continuation. Options, if supplied, have the following meanings:
-a aname
The words are assigned to sequential indices of the array variable aname, starting at 0. aname is unset before any new values are assigned. Other name arguments are ignored.
-d delim
The first character of delim is used to terminate the input line, rather than newline.
.....Tror jeg fant ut av det.. Default shell i Squeeze er Dash, ikke bash. -d parameteren er kun støttet i bash. Hvis du kjører scriptet slik som dette "sh rename-files.sh" så benytter du sannsynligvis dash, siden sh peker på Dash i nyere Debian. Jeg kjører imidlertid scriptet direkte med ./rename-files.sh, hvor #!/bin/bash da forteller at bash skal benyttes, alternativt kan du kjøre det slik "bash rename-files.sh"