[12:21] <arve> hm, noen god måte å finne ut hvilken 'find' som er i bruk?
[12:21] <arve> trenger å gjøre noe med find over et stort sett med filer, og BSD find støtter ikke printf
[12:45] <RoyK> støtter vel --exec, vel?
[12:47] <arve> altså, joda
[12:48] <arve> men jeg trenger å gjøre følgende: Finne alle mapper som inneholder filer som matcher et mønster, og så printe ut de mappene
[12:49] <arve> i gnu find ser det sånn ut: find . -type f -name "*.m4a" -printf "%h\n" | sort -u
[12:50] <arve> i bsd find må jeg gå omveien via xargs og sort --unique
[12:50] <arve> noe som er veldig mye tregere
[12:50] <arve> og hadde tenkt å gjøre scriptet noenlunde portabelt
[12:54] <RoyK> kanskje bruke noe litt mer avansert?
[12:54] <RoyK> perl rekurserer kataloger raskt og greit - sikkert python også - eller js med node
[12:54] <RoyK> eller C :P
[12:56] <arve> tja, nei
[12:56] <arve> det jeg skal _gjøre_ i selve mappene er ikke allverdens avansert
[12:56] <arve> og den skal traversere tilfeldige kataloghierarki
[12:57] <arve> så bash gjør jobben
[12:57] <arve> løsningen er ellers enklere enn jeg tenkte:
[12:58] <arve> find --version > /dev/null 2>&1 || FIND="bsd"
[13:04] <RoyK> find på OS X 10.11 El Capitan har ikke --version :P
[13:04] <RoyK> ah - det er jo det du sjekker etter der
[13:05] <RoyK> kanskje lettere å sjekke OS med uname?
[13:05] <RoyK> uansett er det nok ikke spesielt vanskelig å skrive noe sånt i perl
[13:05] <arve> find på BSD sånn generelt har ikke verken printf eller version
[13:06] <RoyK> …og det er bittelitt mer fleksibelt
[13:06] <arve> tja
[13:06]  * RoyK liker ikke BSD noe særlig
[13:06] <RoyK> eller python, da
[13:06] <arve> resten av scriptet er sånn omtrent tjue linjer
[13:06] <RoyK> eller QBASIC
[13:06]  * arve liker ikke perl
[13:06]  * RoyK gjør
[13:07] <arve> er altfor mange som skriver perl som ser ut som linjestøy
[13:08] <arve> og i dette tilfellet er ikke det jeg skal verre enn at jeg på hver enkelt katalog med en match skal kjøre en kommando, og logge outputen av den til fil
[13:09] <RoyK> jeg skriver ikke støy som ser ut som linjestøy ;)
[13:10] <RoyK> s/støy/perl/
[13:10] <RoyK> du kan obfuskere kode i alle språk
[13:10] <RoyK> sjøl om kanskje perl har gått inn for at folk skal gjøre det
[13:11] <arve> my point exactly
[13:11] <arve> perl oppfordrer i litt for stor grad til det
[13:12] <RoyK> det betyr ikke at jeg gjør det ;)
[13:12] <RoyK> skriver man obfuskert kode og så plukker opp et skript et år eller to seinere, er det ikke alltid så lett å fortsette arbeidet
[13:13] <arve> selve datasettet jeg får ut av dette lille shellscriptet kommer jeg nok til å bruke python på
[13:16] <RoyK> da er det raskere å rekursere i python også
[13:17] <RoyK> find er rimelig enkel
[13:32] <Mathias> RoyK: fortran!
[13:33] <Mathias> python har noen snasne bibliotek for å behandle mapper/filer
[13:33] <Mathias> husker ikke hva det heter, men gugel vet nok
[13:34] <RoyK> Mathias: FORTRAN77, da
[13:35] <Mathias> har vurdert å lage et eget språk
[13:35] <Mathias> består av at dunker trynet i tastaturet til noe skjer
[13:35] <Mathias> ca. sånn jeg koder uansett, hihi
[13:45] <RoyK> https://www.xkcd.com/1833/ ?
[13:52] <Malinux> hm, det er bedre enn hva jeg får til :)
[13:54] <RoyK> *flire*
[13:55] <RoyK> etpar kolleger (spanjoler begge to) satte telefonen på høyttalende for å følge med på en telefon han ene fikk fra "microsoft" om at maskina er hacka
[13:55] <RoyK> han sa ikke noe om at det var Fedora på den, da...
[13:56] <arve> @Mathias: det språket eksisterer allerede
[13:56] <arve> det heter Brainfuck
[13:57] <arve> skrev en gang i tida en brainfuck-parser som spyttet ut javascript og evaluerte det
[13:58] <arve> ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
[13:58] <arve> Hello world I Brainfuck
[14:00] <arve> det finnes også JSFuck
[14:00] <arve> som bruker de seks samme symbolene, men er gyldig javascript
[14:01] <arve> https://en.wikipedia.org/wiki/JSFuck
[14:01] <arve> s/de seks/seks av de/
[16:27] <arve> jamen, så herregud, da bash
[16:27] <arve> nå er det like før jeg tar frem python for dette og
[16:30] <RoyK> hehe
[16:31] <RoyK> etter litt knoting med bash, er det ofte veldig befriende å bruke noe annet ;)
[16:35] <arve> altså, problemet er å sikre seg mot "smarte" ting som fil og mappenavn med linjeskift i filnavnene
[16:39] <arve> finnes heller ingen god måte å dytte outputen fra find inn i et array
[16:42] <RoyK> så bruk noe bedre, da :P
[16:42] <RoyK> hadde du begynt med python (eller perl), hadde du nok vært ferdig for lengst
[16:42] <RoyK> og begge p-ene kommer jo med alt av distroer
[16:42] <RoyK> …og begge har jo veldig god regex-støtte
[16:43] <arve> joda
[16:43] <arve> men for all del, har ikke sittet med det siden i sted
[16:56] <arve> men: find (find-streng)| while read filename; do [kode]; done
[16:57] <skandix> hva du leter etter o.O?
[16:58] <arve> leter ikke etter noe
[16:58] <arve> har en katalog med 200GB med musikkfiler av ymse art
[16:59] <skandix> aha
[16:59] <arve> og skal kjøre analyse av loudness på filene
[16:59] <skandix> uhh
[16:59] <skandix> hva bruker du til å analysere de?
[16:59] <arve> r128x
[17:00] <skandix> "r128x, a tool for loudness measurement of files on Mac OSX Intel."
[17:00] <skandix> hmm, kult
[17:01] <skandix> burde kanskje gjort det selv på de filene jeg skal scrape fra soundcloud..
[17:01] <RoyK> loudness som i lydnivå?
[17:03] <RoyK> det er jo noe som heter "loudness" som finnes på diverse anlegg for å booste diskant og bass når man spiller lavt, sånn for å kompensere for hva øret gjør
[17:03] <arve> nei, her er det snakk om i lydnivå i forhold til digital fullskala
[17:03] <arve> altså, _subjektivt_ lydnivå
[17:03] <RoyK> ffmpeg har vel støtte for sånt
[17:04] <RoyK> "i forhold til"?
[17:04] <arve> ja, altså, den høyeste lyden du kan ha digitalt er 0.0 dBFS
[17:04] <RoyK> http://www.sprakradet.no/sprakhjelp/Skriverad/Feil-bruk-av-ord-og-uttrykk/I-forhold-til/
[17:04] <arve> ehh
[17:04] <arve> ok,
[17:05]  * RoyK misliker *sterkt* folk som snakker om "i forhold til" når de mener "angående" eller "om" eller "med tanke på" eller "rundt" eller noe
[17:05] <arve> men i dette tilfellet står jeg på at "i forhold til" er riktig
[17:05] <RoyK> og spesielt når folk flirer og fortsetter
[17:05] <arve> fordi det er snakk om en relativ og målbar forskjell mellom A og B
[17:05] <RoyK> skjønner
[17:05] <arve> 0.0 dBFS er full skala digitalt
[17:06] <RoyK> 0dB er jo en vanlig greie også på analogt
[17:06] <arve> LUFS er et relativt mål av et vektet snitt av lyd over tid
[17:06] <arve> som ligger x antall desibel under
[17:06] <arve> den måleenheten kalles "LUFS"
[17:06] <RoyK> det var i hvert fall det en gang på åttitallet da jeg dilla med nærradio
[17:06] <arve> 0 dB analogt betyr noe litt annet (og litt forskjellig i forskjellige sammenhenger)
[17:07] <arve> men i lydfiler representert ved N antall bits, så er 0.0 dB den høyeste verdien et sample kan ha
[17:07] <RoyK> kjente ikke til dBFS, men ser at den er heldigital
[17:07] <RoyK> ah - skjønner
[17:07] <arve> (det blir litt mer flytende under prosessering av lyd i DAW-er og slikt, fordi de bruker flyttall
[17:08] <RoyK> DAW?
[17:08] <arve> Digital Audo Workstation
[17:08] <RoyK> har tenkt litt på det med "cd-kvalitet" - det blir jo ganske bedritent på lavt lydtrykk
[17:08] <RoyK> du får jo rimelig få bits når alt er lineært
[17:09] <arve> tja, nei
[17:09] <RoyK> men blir sikkert bedre med flere bits
[17:09] <arve> antall bits i digital lyd bestemmer utelukkende en ting: støygulvet
[17:09] <RoyK> arve: det er jo bare et bittog, så har du mye dynamikk, så får du brukt veldig få bits på partiene med lavt lydtrykk
[17:10] <RoyK> du bruker jo ikke alle 16  når lyden er på 20% av maks
[17:10] <arve> nei, men det er ikke slik at digital lyd er "diskrete nivå" eller trappetrinn
[17:11] <arve> https://xiph.org/video/vid1.shtml
[17:11] <arve> https://xiph.org/video/vid2.shtml
[17:11] <arve> se de to
[17:12] <arve> (I praksis: En DAC kan perfekt reprodusere et signal med _1_ bit data
[17:19] <RoyK> altså - jeg prøvde å gjøre et opptak med audacity nå med lite lyd/støy rundt meg, og fikk ± 2-3 bit
[17:19] <RoyK> det betyr at den ikke klarer å reprodusere kvaliteten i bakgrunnen, siden den forsvinner
[17:19] <RoyK> jeg sjekka bitdybde med en hexdump - det er ganske tydelig hvor mye data som lagres
[17:58] <arve> det er vanskelig å forklare dette uten å bruke syntetiske toner, men:
[17:59] <arve> Om du har en støyfri nok signalgenerator som du spiller inn via en støyfri nok DAC, og du klarer å sette nivået slik at verdien tilsvarer 1 bit (så -90.31 dBFS)
[17:59] <arve> og du så omvandler det tilbake til analogt, så vil du ende med det samme signalet
[18:45] <arve> oh well, der gikk ideen om å gjøre dette portabelt i bash rett ut av vinduet
[18:45] <arve> fant ikke noe r128-verktøy i Linux som gjør all analysen jeg vil ha
[18:46] <arve> (som er tilgjengelig i kildekodeform)
[18:48] <Mathias> arve: tenker mathiasfuck
[18:49] <Mathias> bruker alle tegnene på tastaturet og noen fler
[18:49] <arve> det som er så fint med brainfuck
[18:49] <arve> den ignorerer alle tegn den ikke kjenner
[18:49] <arve> og i prinsippet er alle stringer som kan uttrykkes gyldig Brainfuck
[18:55] <arve> og faen
[18:56] <arve> http://imgur.com/a/3WWE5
[18:57] <arve> når jeg redirectet outputen til en fil