-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
output matching different between windows and linux. I created a database of filehashes which is around 340MB. When i try to query around 100 mp3 files my output is different between my windows machine and my raspberri pi. The database is identical, the query is identical but the windows machine finds significantly more matches. Both are running python 3.9. Database was created on the windows machine and transfered to the pi. Anyone encountered something similar? #92
Comments
It could be that the mp3 decoder gives a slightly different result on the
two architectures. Try converting the query to an afpk file (preprocessed
peaks) then run the query on both machines; the results should be the same.
MP3 decoders (even different versions of mpg123) can differ in their net
delay, and an identically-timed query will get many more hits than a random
time alignment.
DAn.
…On Sun, Nov 6, 2022 at 13:06 CoenGoedhart1 ***@***.***> wrote:
—
Reply to this email directly, view it on GitHub
<#92>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEGZUPF3NCCSRY4BQKK64TWG7XRFANCNFSM6AAAAAARYRCJOY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Hi, thanks for responding. I did some tests. having the same query and database on both windows and linux. I tried with the original mp4 files, afpk files (the peaks) and the precomputed afpt files. On windows the mp4 query finds significantly more matches with the mp4 files than the aftp and afpk files. both afpk and afpt outputs are identical on windows and linux. Linux finds also siginificantly more matches with the mp4 comparing to aftp and afpk. However linux mp4 finds less matches than windows mp4. On both machines i installed the newest ffmpeg available. My goal is to find the same exact matches on my linux system as the matches i found on windows using the mp4 files. "MP3 decoders (even different versions of mpg123) can differ in their net can i conclude from this that a possible solution could be to build up the entire database on the linux system since creating the database on a different platform could interfere the delay? |
That's puzzling, but I think your results point to differences in the audio
codec on the different platforms.
If you're querying with the originals, your very-high matches may be
illusory: If the reference and query are the exact same audio (through the
same codec) or an exact prefix, then all the hashes will match - something
that will never happen with a real, independent query. So I wouldn't get
too hung up on those numbers. If the query is actually a separate audio,
my guess would be the match count would be equivalent (on average, though
perhaps not identical) on both platforms. I wouldn't expect a significant
difference between which platform you built the database on, and I don't
think it's a big problem to mix reference items ingested on both platforms.
But I'm not sure, and your empirical results are interesting.
DAn.
…On Mon, Nov 7, 2022 at 7:55 AM CoenGoedhart1 ***@***.***> wrote:
Hi, thanks for responding. I did some tests. having the same query and
database on both windows and linux. I tried with the original mp4 files,
afpk files (the peaks) and the precomputed afpt files. On windows the mp4
query finds significantly more matches with the mp4 files than the aftp and
afpk files. both afpk and afpt outputs are identical on windows and linux.
Linux finds also siginificantly more matches with the mp4 comparing to aftp
and afpk. However linux mp4 finds less matches than windows mp4. On both
machines i installed the newest ffmpeg available. My goal is to find the
same exact matches on my linux system as the matches i found on windows
using the mp4 files.
"MP3 decoders (even different versions of mpg123) can differ in their net
delay, and an identically-timed query will get many more hits than a random
time alignment."
can i conclude from this that a possible solution could be to build up the
entire database on the linux system since creating the database on a
different platform could interfere the delay?
—
Reply to this email directly, view it on GitHub
<#92 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEGZUOGWCN34U7OBZKPJQTWHD343ANCNFSM6AAAAAARYRCJOY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Converting the queries to WAV instead of mp3/mp4 (then copying between
platforms) should also ensure they get into audfprint as the exact same
values, to further confirm that the codec is responsible.
DAn.
…On Mon, Nov 7, 2022 at 08:24 Dan Ellis ***@***.***> wrote:
That's puzzling, but I think your results point to differences in the
audio codec on the different platforms.
If you're querying with the originals, your very-high matches may be
illusory: If the reference and query are the exact same audio (through the
same codec) or an exact prefix, then all the hashes will match - something
that will never happen with a real, independent query. So I wouldn't get
too hung up on those numbers. If the query is actually a separate audio,
my guess would be the match count would be equivalent (on average, though
perhaps not identical) on both platforms. I wouldn't expect a significant
difference between which platform you built the database on, and I don't
think it's a big problem to mix reference items ingested on both platforms.
But I'm not sure, and your empirical results are interesting.
DAn.
On Mon, Nov 7, 2022 at 7:55 AM CoenGoedhart1 ***@***.***>
wrote:
> Hi, thanks for responding. I did some tests. having the same query and
> database on both windows and linux. I tried with the original mp4 files,
> afpk files (the peaks) and the precomputed afpt files. On windows the mp4
> query finds significantly more matches with the mp4 files than the aftp and
> afpk files. both afpk and afpt outputs are identical on windows and linux.
> Linux finds also siginificantly more matches with the mp4 comparing to aftp
> and afpk. However linux mp4 finds less matches than windows mp4. On both
> machines i installed the newest ffmpeg available. My goal is to find the
> same exact matches on my linux system as the matches i found on windows
> using the mp4 files.
>
> "MP3 decoders (even different versions of mpg123) can differ in their net
> delay, and an identically-timed query will get many more hits than a
> random
> time alignment."
>
> can i conclude from this that a possible solution could be to build up
> the entire database on the linux system since creating the database on a
> different platform could interfere the delay?
>
> —
> Reply to this email directly, view it on GitHub
> <#92 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAEGZUOGWCN34U7OBZKPJQTWHD343ANCNFSM6AAAAAARYRCJOY>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
I did some more testing. I now have 3 systems, 1 winsows, 1 pi with linux, 1 virtual linux docker system. I created a database using the pi and have 585 queries with audio downloaded from a different source. In the database are the original videos and the queries are tweets, so it's not the original files. I found out that it does not matter on which system you create the database. I created one on linux and one on windows. when using the one on the other system results stay consistent. So, adding mp4 files to the database is for all platforms the same. Only the reuslts of the query are different. The docker and pi outputs exactly the same. The windows system finds significantly more matches. I also tried to converting to wav. On the windows machine i did the following mpeg command: On the linux machine i also converted the same mp4 files to wav: I think it can only be ffmpeg right? im not sure how to investigate further |
Yes, I think it's the encoding of the queries and differences in the codec
on linux/windows. It may be a licensing thing - Windows may have a
high-quality, commercial decoder, but linux may be limited to an inferior
open-source one. And it might be different for the queries (from tweets)
but the same for the reference items because of a different codec being
used for the audio from the two sources.
One way to debug further would be to duplicate the query decoding being
performed by audfprint, then look closely at the debug output from ffmpeg
on each platform to see what library it reports using.
It should just be "ffmpeg -i <input_file> -f s16le -ac 1 -ar 11025
out.pcm". For example, on my machine I get:
***@***.***:~/Downloads$ ffmpeg -i solo.mp3 -f s16le -ac 1 -ar
11025 out.pcm
ffmpeg version 5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
built with Apple clang version 14.0.0 (clang-1400.0.29.102)
configuration: --prefix=/usr/local/Cellar/ffmpeg/5.1.2 --enable-shared
--enable-pthreads --enable-version3 --cc=clang --host-cflags=
--host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl
--enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame
--enable-libopus --enable-librav1e --enable-librist --enable-librubberband
--enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora
--enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx
--enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2
--enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype
--enable-frei0r --enable-libass --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex
--enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack
--disable-indev=jack --enable-videotoolbox
libavutil 57. 28.100 / 57. 28.100
libavcodec 59. 37.100 / 59. 37.100
libavformat 59. 27.100 / 59. 27.100
libavdevice 59. 7.100 / 59. 7.100
libavfilter 8. 44.100 / 8. 44.100
libswscale 6. 7.100 / 6. 7.100
libswresample 4. 7.100 / 4. 7.100
libpostproc 56. 6.100 / 56. 6.100
Input #0, mp3, from 'solo.mp3':
Metadata:
encoder : Lavf56.15.102
Duration: 00:00:14.86, start: 0.025057, bitrate: 64 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 64 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (mp3 (mp3float) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, s16le, to 'out.pcm':
Metadata:
encoder : Lavf59.27.100
Stream #0:0: Audio: pcm_s16le, 11025 Hz, mono, s16, 176 kb/s
Metadata:
encoder : Lavc59.37.100 pcm_s16le
size= 320kB time=00:00:14.83 bitrate= 176.4kbits/s speed=1.02e+03x
video:0kB audio:320kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.000000%
I'm actually not sure how to pick out the mp3 decoder there, but it would
be interesting to compare the results for running on Windows and Linux
anyway.
DAn.
…On Mon, Nov 7, 2022 at 4:15 PM CoenGoedhart1 ***@***.***> wrote:
I did some more testing. I now have 3 systems, 1 winsows, 1 pi with linux,
1 virtual linux docker system. I created a database using the pi and have
585 queries with audio downloaded from a different source. In the database
are the original videos and the queries are tweets, so it's not the
original files. I found out that it does not matter on which system you
create the database. I created one on linux and one on windows. when using
the one on the other system results stay consistent. So, adding mp4 files
to the database is for all platforms the same. Only the reuslts of the
query are different. The docker and pi outputs exactly the same. The
windows system finds significantly more matches.
I also tried to converting to wav.
On the windows machine i did the following mpeg command:
for %i in (*.mp4) do ffmpeg -i "%i" "%~ni.wav"
when querying windows had the same results but linux did far worse then
the mp4 files.
On the linux machine i also converted the same mp4 files to wav:
for i in *.mp4; do ffmpeg -i "$i" "${i%.*}.wav"; done
transfering to windows and querying again gave the same good results, on
linux the same bad results.
I think it can only be ffmpeg right? im not sure how to investigate further
—
Reply to this email directly, view it on GitHub
<#92 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEGZUKUT7GWGSE2G4TYSK3WHFWPHANCNFSM6AAAAAARYRCJOY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Hi DAn, thank you so much! I did manage to recreate the results of the windows machine on the raspberri pi. Converting the mp4 files to wav with the sample rate of 11025 and having FFMPEG on False on the audio_read.py gave me the exact same results. Im looking into using the same decoder on both platforms but for now i have a workable solution! Again, thnx for your help! |
No description provided.
The text was updated successfully, but these errors were encountered: