Skocz do zawartości

danadam

Zarejestrowany
  • Postów

    58
  • Dołączył

  • Ostatnia wizyta

Odpowiedzi opublikowane przez danadam

  1. A czemu nie podać linka do artykułu?

    https://www.avtest.pl/artykuly/technika/item/791-moc-a-impedancja-jak-dobierac-wzmacniacze-i-sluchawki

     

    Ile mocy potrzeba, zależy od czułości/efektywności słuchawek, ich impedancji i jak głośno chcemy słuchać. Tutaj jest w miarę prosty kalkulator: https://www.hear.audio/2019/06/01/headphone-power-calculator/

     

    Co do wartości z artykułu, to wg mnie raczej nieosiągalne jeśli ceni się swój słuch (no ewentualnie, przy bardzo niewydajnych słuchawkach). Przykładowo, moje:

    • Tin T2: impedancja 16 Ohm, efektywność 102 dB/mW, przy 390 mW to będzie 128 dB SPL. Nie, dziękuję.
    • Sennheiser HD 650: impedancja 300 Ohm, czułość 103 dB/Vrms, przy 20 mW to będzie 112 dB SPL. Do klasyki, jak chcę głośno posłuchać, może. Normalnie, nie, dziękuję.
  2. W dniu 7.04.2022 o 12:31, Artorias napisał:

    Skądś jednak mają statystyki na stronie którą podałem. Nawet winyle stosunkowo świeżych materiałów mają często 3 razy lepszą dynamikę od ich cyfrowego odpowiednika. Raczej sobie z czapy tam nie wrzucają danych

    Na górze strony masz napisane:

    Cytat

    Vinyl rips ... Often they just use the same digital master that CDs, downloads and streams share but seem more dynamic because of the analog ripping process.

    A tutaj więcej szczegółów:

     

  3. W dniu 14.02.2021 o 12:38, saudio napisał:
    Cytat

    Human hearing is able to recognise time definition, (the difference in incoming sounds), down to 10 microseconds and latest research has found that it may be as low as 5 microseconds. [...] For these reasons, [...] high sampling rates are required to ensure total reproduction of the soundwaves arriving at micro second intervals to the microphone.

    Już zwykłe 16/44 ma rozdzielczość czasową liczoną w nanosekundach i mniej: https://troll-audio.com/articles/time-resolution-of-digital-audio/

    To niespecjalnie budzi zaufanie do reszty informacji na tej stronie. Ale jako materiał marketingowy, 5+ 🙂

    • Haha 1
  4. 10 godzin temu, hibi napisał:

    Pliki flac-mqa ważą ile 10% więcej od zwykłych flac 44/16.

    O ile się nie machłem, to na podstawie plików z 2L test bench albo brakuje jednego zera albo 16 pomyliło się z 24:

    album   cd size     mqa size    difference
    038     50136795    99003201    +97%
    048     18863763    52740055    +179%
    053     20848230    39944045    +91%
    106     24368412    50352602    +106%
    092     19006696    52707527    +177%
    --------------------------------------------
    album   44/24 size  mqa size    difference
    038     94853567    99003201    +4%
    048     44675849    52740055    +18%
    053     36774563    39944045    +8%
    106     47949751    50352602    +5%
    092     46953006    52707527    +12%

    (pliki 44/24 zostały stworzone z plików 96/24 przy pomocy:

    sox "input.flac" "output.flac" rate -v 44.1k

     

     

    8 godzin temu, majkel napisał:

    oraz zakres wysokich częstotliwości zakodowanych bodajże na 176400

    Według ich własnego patentu na wejściu do enkodera jest plik 88 albo 96 kHz.

     

     

    8 godzin temu, majkel napisał:

    jakby podbiło realną rozdzielczość choćby o 4 bity, to SNR się poprawi o 24dB.

    Z ciekawości, pliki mqa rozmiarowo odpowiadają flac'om 96/19:

    album   mqa size    96/19 size  difference
    038     99003201    112591295   +13%
    048     52740055    48336552    -8%
    053     39944045    43783093    +9%
    106     50352602    51243379    +1%
    092     52707527    48531705    -7%

    (pliki 96/19 zostały stworzone z plików 96/24 przy pomocy:

    sox "input.flac" "output.flac" dither -p 19

     

    • Like 1
  5. W dniu 30.11.2020 o 11:28, Spawn napisał:

    Jeśli porównujemy MQA do pliku FLAC 16/44 to w takim przypadku MQA jest bezstratny

    Tutaj przykład wyzerowania 8 najniższych bitów w pliku MQA, po czym taki plik nadal jest rozpoznawalny jako MQA: https://audiophilestyle.com/forums/topic/38608-truncating-mqa-files-to-16-bits-and-the-blue-light-still-shines/

    To by oznaczało, że informacja o tym czy plik jest MQA czy nie znajduje się gdzieś w pozostałych 16 bitach i tym samym nawet w porównaniu do FLAC 16/44 MQA nie jest bezstratne.

    W dniu 30.11.2020 o 11:28, Spawn napisał:

    natomiast w porównaniu do pliku 24/192 już jest stratny ponieważ dodatkowe informacje które takowy plik posiada zostają skompresowane stratnie czyli usunięte.

    W przypadku 192 i powyżej to nawet bardzo stratnie. OIMW (stąd i stąd) to w pliku MQA nie ma w ogóle danych z pasma powyżej 44/48 kHz (próbkowanie 88/96 kHz). Te dane są "odzyskiwane" przez zwykły upsampling zdekodowanego pliku 88/96 kHz.

    • Like 1
  6. W dniu 23.11.2020 o 20:03, majkel napisał:

    Porobiłem sobie dziś porównania streamingu YT pod YouTube Music (nie Premium) kontra to, co można usłyszeć (plus zobaczyć) w przeglądarce internetowej na stronie YT. To, co leci jaki streaming muzyczny, ma u mnie 110-180kb/s i brzmieniowo - jakościowo - odpowiada temu, co leci w głośnikach, jak się wybierze jakość filmu z przedziału 240-480p. 144p gra gorzej - ewidentne artefakty kompresji, ten najszerszy przedział jakości jakby tak samo. Z 720p dźwięk już jest czyściejszy niż standardowy stream Music, a 1080p jeszcze lepiej.

    Do wyciągania danych dźwiękowych użyłem foobara z pluginem do YouTube. Zaletą tego jest brak reklam. Wady:

    - jakość dźwięku z niższego dostępnego przedziału

    - niektóre linki do filmów w ogóle nie wchodzą. Dziwnym trafem te najlepiej grające. Odnośnie przykładów: Rahim Alhaj koncert w KEXP, Jilax Universo Paralello 2019, Radio Intense i inne

    U mnie (linux) w przeglądarce tylko 144p ma większą kompresję audio, format code 250 (opus, ~70 kbps):

     

    yt_144p.png.38c62022e58bfa3068e305438dfd8488.png

     

    Od 240p w górę jest to samo, format code 251 (opus, ~128 kbps, o ile mi wiadomo to najwyższa możliwa jakość):

     

    yt_240p.png.f57dfa6d6e77d5c30392d12b3ed5d4fb.png

     

    yt.1080p.png.7ef7b9279dfdf095231d44b4a1e1aca4.png

     

    Po ściągnięciu przy użyciu "youtube-dl":

    ]$ youtube-dl -F https://www.youtube.com/watch?v=U9qmsX4c78Y
    [youtube] U9qmsX4c78Y: Downloading webpage
    [info] Available formats for U9qmsX4c78Y:
    format code  extension  resolution note
    249          webm       audio only tiny   61k , opus @ 50k (48000Hz), 17.18MiB
    250          webm       audio only tiny   80k , opus @ 70k (48000Hz), 22.04MiB
    140          m4a        audio only tiny  130k , m4a_dash container, mp4a.40.2@128k (44100Hz), 41.41MiB
    251          webm       audio only tiny  153k , opus @160k (48000Hz), 41.84MiB
    278          webm       256x144    144p   99k , webm container, vp9, 24fps, video only, 29.99MiB
    ...
    
    ]$ youtube-dl -xtf 250 https://www.youtube.com/watch?v=U9qmsX4c78Y
    ...

     

    "ffprobe" pokazuje odpowiednio 65 i 126 kbps:

    Input #0, ogg, from 'Rahim AlHaj - Full Performance (Live on KEXP)-U9qmsX4c78Y.opus':
      Duration: 00:45:33.93, start: 0.007500, bitrate: 65 kb/s

    i

    Input #0, ogg, from 'Rahim AlHaj - Full Performance (Live on KEXP)-U9qmsX4c78Y.opus':
      Duration: 00:45:33.93, start: 0.007500, bitrate: 126 kb/s
    

     

    • Like 1
    • Thanks 1
  7. 15 godzin temu, audionanik napisał:

    Tylko że w tym przypadku (środkowy rysunek) materiałem źródłowym dla radosnej twórczości pokazanej na trzecim grafie nie jest już sinusoida.;)

    W ten sposób to z trzech- czterech czy tam siedmiu punktów można se narysować kota, dom, logo Kindle czy co tam chcesz, a raczej wiesz z góry co ma być narysowane:D

     

    Nie, nie można narysować "co tam chcesz" i tak, z góry wiadomo co ma być narysowane: ma być narysowany sygnał z pasmem ograniczonym do 22'050Hz. To redukuje ilość możliwych połączeń do jednego.

  8. 10 godzin temu, SlawekR napisał:

    Na oscyloskopie owszem, na podstawie, ciągle powtarzającego się,  przebiegu okresowego, jeśli trwa wystarczająco długo, to jest on w stanie uśrednić że jest to sinusoida.

    Tak dla jasności, oscyloskop w tej prezentacji jest czysto analogowy, więc zakładam, że przez "on" masz na myśli DACa, który był "testowany".

     

    10 godzin temu, SlawekR napisał:

    Ale gdybyś wziął próbkę dla jednego okresu przebiegu, czy nawet dwóch albo trzech

    3 okresy fali 20kHz wygenerowane z próbkowaniem 352'800 Hz, skonwertowane do 44'100 Hz i z powrotem do 352'800 Hz. Jasne, te 7 próbek to za mało żeby dokładnie odtworzyć pierwotną sinusoidę, ale nie powiedziałbym, że "przypomina wszystko, tylko nie sinusoidę":

     

    short.thumb.png.cdfc7a4bfef4695054f14bbc0aee2556.png

     

    10 godzin temu, SlawekR napisał:

    Przykład z sinusoidą stanowił uproszczenie sytuacji rzeczywistej, bo realnie taki rzadko występuje w naturalnych warunkach

    Uff, to dobrze, bo fale ograniczone tylko do 3 okresów również 🙂

    A jeśli już mówimy o naturalnych warunkach to wypadałoby też wspomnieć na jakim poziomie w porówaniu do całego spektrum te graniczne częstotliwości zwykle występują (czytaj: na niskim), tak żeby być świadomym skali problemu (albo nie-problemu).

     

    10 godzin temu, SlawekR napisał:

    Ale to już wchodzimy w technikalia takie, gdzie pewnie większości populacji film się urywa

    I dzięki temu cały ten audiofilski interes się kręci 🙂

     

  9. 18 godzin temu, audionanik napisał:

    W skrócie i uproszczeniu - kierunki dochodzenia dźwięku (a więc i pozycjonowanie źródeł) rozpoznajemy min.(bo nie tylko) dzięki  "pomiarom" opóźnień z jakim czoło fali dociera najpierw do jednego potem do drugiego ucha; jesteśmy w stanie "wyłapać" opóźnienia o rząd  wielkości (lub pieć razy, już nie pamiętam) krótsze niż okres najwyższej słyszalnej częstotliwości - w każdym razie przydaje się tu trochę więcej próbek opisujących kształt fali niż dwie na 50 mikrosekund.

    Time resolution of digital audio:

    A frequent claim by detractors of digital audio is that the time resolution is equal to the sampling interval, 22.7 μs for the CD format. This is incorrect. [...] With CD quality audio, 16 bits at 44.1 kHz, the best-case time resolution is obtained with a full-scale signal at 22.05 kHz. The above formula then yields 110 ps. For a more typical 1 kHz signal at -20 dB, i.e. with an amplitude of 0.1, the same calculation produces a value of 24 ns. Although not nearly as good as the best case, it is still 1000 times better than the erroneously claimed limit of one sample interval.

     

    7 godzin temu, SlawekR napisał:

    Praktyka jest taka, że wystarczy spróbować zapisać przy takich parametrach sinusoidę o częstotliwości 20kHz. I jak się źle trafi, to po takim zapisie i ponownym odczycie, ta pierwotna sinusoida będzie przypominać wszystko, tylko nie sinusoidę,

    Hm... na oscyloskopie dalej wygląda jak sinusoida:

     

    • Thanks 1
  10. 21 godzin temu, Setmag napisał:

    Kompresja w Spotyfy odpowiada rozdzielczością MP3-ce  320kb/s

    Zawsze czytałem, że Vorbis jest nowszym i lepszym kodekiem niż mp3, więc nie byłbym pewien czy "odpowiada".

     

    21 godzin temu, Setmag napisał:

    natomiast jakość Tidala w HiFi to 1411 kb/s

    Moim zdaniem to nie jest prawidłowe porównanie. 320 kbps to jest to co Spotify fizycznie przesyła po kablu, więc to powinno być porównane do tego co Tidal fizycznie przesyła po kablu, czyli pewnie ~900 kbps (powiedzmy, że to średnia kompresja FLACa).

  11. Dnia 10/8/2017 o 14:25, awayeah napisał:

    Jak to jest MQA to chyba ilość pobieranych danych nie będzie się jakoś różniła od FLAC 16/44.1

     

    Dnia 10/8/2017 o 14:38, all999 napisał:

    Czyli w paczce odpowiadającej objętościowo 16/44 dostaję muzykę w 24/96?

     

    Dnia 10/8/2017 o 16:39, Spawn napisał:

    W teorii mqa masz plik wielkosci odpowiadajacej 16/44 ale tam niby sa jakies dodatkowe informacje

     

    Hm... Wszędzie piszą, że strumień mqa z tidala to 24/44 (albo 48).

     

     

    20 godzin temu, The Grand Wazoo napisał:

    Co ciekawe, jak np. Mojo, który nie obsługuje MQA ustawimy w opcjach jako Redender device to Mojo "przepuszcza" sygnał MQA bez ingerencji (chyba) i na wyjściu mamy pliki w wyższej częstotliwości. Jak ustawimy jako Decoder device, to niestety obcina do 44kHz.

    Chyba trochę na odwrót. Jak ustawisz w aplikacji "decoder", to aplikacja przepuszcza 24/44 bez ingerencji, a DAC jak ma pełną obsługę mqa (czyli jest dekoderem, np. Mytek) to sobie odpakowuje. Jak nie ma, to odtwarza 44.

    Natomiast jak w aplikacji ustawisz "renderer", to aplikacja odpakowuje do 24/88 i to przesyła do DACa. DAC, jeśli obsługuje mqa (czyli jest rendererem, np. Dragonfly), może to upsamplować do 176 (chociaż tu nie jestem pewien czy akurat Dragonfly to potrafi) albo tylko zastosować jakiś filtr, w zależności od tego czy materiał źródłowy to był 176 czy 88. Jeśli DAC nie obsługuje mqa to po prostu odtwarza 88, które dostał z aplikacji.

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Zarejestruj się aby mieć większy dostęp do zasobów forum. Przeczytaj regulamin Warunki użytkowania i warunki prywatności związane z plikami cookie Polityka prywatności